Our clients
HEARRT
- KUFU Finance
Software & AI systems engineering
Click anywhere to skip
AI and software development
We build custom automation and dashboards on top of Tally and Busy—so your team gets better visibility, faster workflows and fewer manual tasks without replacing the tools you already use.
For established businesses with 10+ staff. Fixed-price projects from ₹1.5 lakh, one-time. Usually delivered in about 30 days.
Our clients
HEARRTIndustries
Manufacturing, finance, healthcare supply and property. We build the systems that run the daily work — not dashboards that nobody opens.
Tap any project to read the full story.
Featured · LiveOwner's dashboardBusy
We helped a three-branch distributor find out why a record sales year left them borrowing to the limit. One screen each morning showed who owed money and which stock wasn't selling, so the owner could act on it.
Case study 03 · LiveAI + dataNamed client
We helped Jensen Instrument Technologies stop pricing from memory. Staff ask a normal question, like "how much is a retractor?", and get the price with the real invoices behind it.
DeliveredWhatsAppLead follow-up
We helped a business that paid for every enquiry follow up on every one of them. Every lead now gets a WhatsApp reply straight away, follow-ups go out on their own, and the sales team starts each day knowing who to call.
Read the case studyWe build software that helps businesses automate work, manage operations and grow.
Websites that bring enquiries and customers.
Automate repetitive tasks and workflows with AI.
One automated system has sent 150 daily briefings with 253 of 253 emails delivered.
Handle calls, qualify leads and book appointments automatically.
Manage customers, inventory, sales, purchasing and operations in one system.
Custom software built around the way your business works.
See your sales, costs, margins and operations in one place.
A distributor's month-end pack went from 9 working days to every morning.
Connect the tools you already use and eliminate duplicate data entry.
208,617 invoice lines synced from one accounting system, searchable in under 70 ms.
Builds we can quote up front. Each one is a fixed price agreed in writing, paid 40 / 40 / 20, and usually live in 30 to 45 days.
Supplier invoice PDFs read and posted into Tally or Busy as purchase vouchers. Your team only checks what it flags.
See it on your invoices From ₹1.5 lakhPrivate AIA private assistant your team asks in plain English. Every answer shows the document and page it came from.
Built before: 14 years of invoices answered in about a minute.
Try it on your documents From ₹1.5 lakhWhatsApp · CRMEvery enquiry answered in a minute, then followed up on WhatsApp, email and SMS until they reply. Your team is told who to call first.
Fix my follow-up From ₹1.5 lakhTally · Busy · ZohoMargins, stock, dues and every branch on one screen, refreshed every morning from the accounting system you already run.
Built before: days to get paid 72 → 61 in three months.
See my numbers live From ₹5 lakhReal estate · All IndiaFor real estate developers: every competing project near your site, with units sold, stock left and sales speed each quarter, read from public RERA filings. Any city in India.
See a sample location viewWe learn how your team works today.
We agree the scope, data and rules before we build.
We ship one working part at a time, starting with the most useful.
Tests, monitoring, backups, and help after launch.
Both were left by the clients themselves.
Communication was clear and easy throughout, tasks were handled with care, and everything was delivered in a professional and reliable way.
He is extremely knowledgeable, reliable, and very talented. I would highly recommend Srinath to all those looking for a true professional. 10/10
Both rated 5.0 of 5 on our verified engineering profile, where they can be read in full.
We design, build, connect, test and hand over a system your team uses every day. Projects start at ₹1.5 lakh because below that we would have to skip the parts that make software survive contact with a real business — the tests, the data migration, the handover. Every project begins with a short paid discovery, and that fee is adjusted into the build price.
Yes. We connect the tools your team already uses rather than asking them to abandon them, and we move your existing Excel data into the new system as part of the build.
You do. The code, the data and the accounts are all in your company’s name. There is no licence to keep paying and nothing that stops working if you stop working with us.
Thirty minutes. We learn how your team works today, show you where the time is going, and tell you honestly whether we can help. If we are not the right fit we will say so on that call.
Contact
Tell us the problem. We will say if we can help, and what it will take.
Want a faster answer? Send us the same details on WhatsApp.
Open WhatsApp →Our builds start at ₹1.5 lakh and suit teams of 10 or more, so we're probably not the right fit yet. We'd rather tell you now than waste your time.
Or reach us directly
sri@clovertech.in
+91 91805 66962
How many people work in your company?
Full-time employees
What is your budget for this?
Projects start at ₹1.5 lakh
What do you need most?
Pick the closest one
When do you want to start?
An honest answer helps us plan
Where should we reach you?
We reply within one working day
Here is what happens next:
Our projects start at ₹1.5 lakh and are built for companies with ten or more people. From your answers we would not be the right fit right now, and we would rather say so than take the meeting.
You are welcome to come back as the business grows.
Data pipeline & workflow automation
Every night this system reads public finance sources, matches what it finds to each user's own shares and interests, and emails one ranked briefing when the market opens.
Source: production system audit, 18 August 2026.
An investor who follows a handful of companies and a handful of fund managers has no single place to look. The information is public, but it is scattered across regulatory archives, finance portals and newswires, each with its own format, and none of which knows what that particular investor owns.
For the client this was the product itself. A briefing that arrives late, repeats yesterday's story, or cannot explain why an item is in it does not get opened — and a briefing service that does not get opened has no business.
Open EDGAR and search each company. Open Yahoo and Finviz, check each ticker. Scan the wires. Look up each manager. The same sequence, before any actual thinking could start.
A 13F tells you what a fund holds as raw XML, thousands of rows keyed by CUSIP. Knowing a manager filed is worthless; knowing what they bought and sold is the whole point.
The same story surfaces on three sites over four days. Without a record of what a reader has already seen, an automated feed re-delivers it and becomes noise.
A headline matters enormously to someone holding that position and not at all to someone who does not. Generic newsletters cannot make the distinction, so they hedge and send everything.
At design time the client had no paid market-data contracts and no timeline for getting them. Rather than treat that as a blocker, the ingest layer was built entirely against public web and RSS endpoints — which removed procurement from the critical path and let the pipeline reach production without waiting on anyone.
EDGAR is the authoritative source for filings and is free. Wire-service headlines are discoverable through scoped news search per publisher domain. The client's launch checklist reduced to email and branding decisions.
Every box is a module or a table that exists in the codebase. Data flows top to bottom; each engine reads what the previous one wrote, which is what makes any stage independently re-runnable. A scheduled run and an operator-triggered run execute the identical code path.
One ordering rule was corrected against live output. Ranking originally put source priority first, so a months-old filing from a high-priority source outranked that morning's major press story. Reading real briefings made the error obvious; ranking is now recency-first.
Each is stated with the alternative rejected and the trade-off accepted, because a decision without a cost is usually a decision that was never made.
Licensed feeds from a market-data vendor, or paid wire-service APIs.
A paid-API design would have put the entire pipeline behind a procurement process outside our control. Public endpoints cover the same ground for this use case.
Scraped sources are less structured and can change shape without notice, so adapters need defensive parsing and occasional maintenance. There is no delivery SLA behind them.
The pipeline reached production with zero paid data subscriptions and no procurement dependency.
A single fetch module branching per source, or a queue-based worker per source.
Sources are the part of this system most likely to change. Each one self-registers, so the runner has no knowledge of any specific source and adding one is a new file.
A registry populated by import side effects is indirect — the adapter list is assembled at import time rather than visible in one place.
Eight adapters share one runner. A broken source logs its failure and returns nothing while every other source still delivers.
A single unique constraint at ingest.
A unique key stops the same row being stored twice, but not the same story arriving as a genuinely different row. Readers experience repetition as the system being broken, so the check has to happen on content, where selection happens.
A content-signature lookup against 365 days of history for every candidate item, and a normalisation rule to maintain.
A story re-scraped tomorrow under a new id cannot reach a second briefing — the property subscribers notice most.
Reusing the filing renderer that the in-app viewer already uses.
The display renderer caps at 1,000 holdings, which is right for a web page and wrong for a diff — positions past the cut-off look "new" or "exited" purely because they were truncated. One tracked fund files over three thousand lines.
Two parsers to maintain for the same document format, and a heavier fetch on the enrichment path.
Position diffs are correct for funds of any size, and enrichment runs once per filing rather than on every run.
Generating the summary inline and treating a failure as a failed briefing.
The briefing's value is the matched, de-duplicated, ranked items. Letting a third-party model outage stop a subscriber's mail trades a reliable product for a slightly nicer one.
On a model failure the email goes out without its opening paragraphs, so the reader experience is not uniform across days.
No model failure can block a send. The provider is a configuration value — any OpenAI-compatible endpoint works.
This table compares process, not measured time or cost. A time-saved figure would need a before/after measurement against real subscribers, which has not been run — so none is claimed.
| Briefings delivered | 150 |
| Emails queued / sent / failed | 253 / 253 / 0 |
| News items ingested | 6,350 |
| Scheduled runs green | last 8 of 8 |
| Items missing source attribution | 3,425 → 0 |
| Automated tests | 20 passing |
Commercial and engagement metrics for this system have not been measured, and this document does not estimate them.
A case study that only lists wins is a sales page. These are the open items, in the order we would take them.
TLS termination, error reporting, alerting, service-level objectives, a written runbook, and browser end-to-end tests in CI. Scoped, not yet started.
Per-ticker aggregator pages carry general market stories alongside company news. The fix is to require a company or ticker match in the headline or body before attributing.
Twenty tests cover the critical paths. Matching and de-duplication deserve property-based tests, since that is where a silent regression would be most expensive.
Design around the constraint, not against it. No data budget could have stalled this project; building ingest against public sources removed procurement from the critical path entirely.
AI systems engineering
The AI layer behind a companion app. It has to sound human, stay safe, remember correctly for months, and keep working when the AI provider does not.
This service never talks to a user directly. The product backend sends a JSON payload — who the user is, who the companion is, what was said recently, what safety rules apply — and the service returns the reply. Everything hard about the product lives inside that one call.
It is a dependency, not an app, and that inverts the usual error-handling default. A 500 returned here is a broken screen in someone else's app, attributed to them. The job is to return something useful under degraded conditions and reserve hard errors for when no useful answer exists.
A companion that says "I'm here for you" is a chatbot wearing a name. The premise is a friend texting back — a prompt problem with a hard acceptance test: does it read like a person, at message length?
The prompt asks the companion to surface a crisis helpline on any self-harm disclosure. Sampling means "asks" is not "guarantees". For the one conversation where being wrong is unacceptable, instruction-following is not a control.
A companion that forgets is worthless; one that misremembers is worse. Facts change. Appending everything to the prompt blows the context window and lets stale facts contradict current ones.
Rate limits, 5xx bursts, filters returning null, models that silently reject a parameter. These are normal operating conditions on hosted models — each needs an answer better than a stack trace.
The through-line: all of them are the same class of problem — a probabilistic component sitting on the critical path of a product that has to behave deterministically.
Figure — the safety signal is computed independently of the reply model, so a model that fails to follow instructions cannot remove the helpline. The instruction-resistance layer is unconditional: a caller that disables injection detection still cannot switch it off.
Counts collected from the suite on 1 September 2026; total 487, all passing. The distribution is the argument — the largest blocks are request validation, prompt assembly and error translation, the boundaries where untrusted input arrives and where failures become something the caller can act on. Stated plainly: embedding generation and fact extraction have placeholder test files and no dedicated unit tests, a gap named rather than papered over.
Instruct the model to include it, and test that it usually does.
Sampling makes "usually" the ceiling. For the one conversation where being wrong is unacceptable, an instruction is not a control — the decision has to come from a signal the model does not produce.
A second scoring path to maintain, plus de-duplication logic so a model that does include a helpline does not produce two.
The helpline is guaranteed, region-selected, and never duplicated — independent of what the model sampled.
Append conversation history to the prompt, as most first builds do.
An appended history grows without limit and lets a stale fact sit beside the current one. A companion that misremembers is worse than one that forgets.
A vector store to maintain, with extraction and reconciliation logic that has to be right.
Prompt size stays bounded no matter how long a user has been talking, and a correction replaces the old fact instead of sitting next to it.
Trust the internal caller; sanitise only the user's message text.
The companion's name, tone and personality traits are rendered into the system prompt, where text carries the most authority in the whole request. They arrive from a trusted service but describe user-configurable objects — user-controlled data wearing a trusted badge. Newlines are the specific risk.
Identity fields are collapsed to a single line and length-capped, so an unusually long custom tone is truncated rather than honoured in full.
No request field can introduce a new instruction block, and the model's resistance to injection is not something a caller flag can disable.
Prompt assembly, safety scoring, response parsing and crisis attachment are inputs in, value out — no network, no shared state.
A large share of the behaviour is verified exhaustively in under ten seconds without a single provider call — which is also why the safety logic could be reasoned about at all.
There was no prior system to migrate from. "Before" is the shape this service would have taken with the obvious implementation — the honest baseline the design argued against.
Also delivered: 3,966 lines of production Python across 35 modules, 5,612 lines of test code, five stable error codes, and roughly nine weeks from design to feature-complete, working solo.
Said plainly: these are engineering outcomes, not business outcomes. The service is feature-complete and verified, but not yet measured under production traffic — so no conversion, retention, cost or latency figure appears here.
Operations platform · discrete manufacturing
A mid-sized metal parts manufacturer was running stock on spreadsheets, paper slips and memory. We built one system where every stock movement is recorded, and no stock number is ever typed in by hand.
Confidentiality — this case study uses an anonymised, representative business scenario. Company identity and sensitive information have been intentionally omitted.
The business buys sheet metal, bar stock, fasteners and bought-out components, converts them on the shop floor, and ships finished assemblies to industrial customers. It had grown faster than its tools: inventory information existed in several places at once, each partially correct, and the gaps showed up where they hurt most — on the production floor, and in cash tied up in the wrong stock.
The store kept a master spreadsheet, purchasing kept its own order tracker, and production supervisors noted usage on paper slips. The three rarely agreed, and nobody could say with confidence which was right.
Materials issued to the floor were written down and typed in days later. Urgent issues during a busy shift were often never recorded, so book stock drifted steadily away from what was physically on the racks.
With no reliable reorder signal, a missing bracket or fastener was typically found when an assembler reached for it. Jobs waited on expedited purchases for parts that cost very little but stopped work entirely.
To avoid repeat shortages, buyers padded orders — tying up cash in material the floor did not need while the parts that actually stopped work still ran out.
Figure — documents post movements; balances are derived from movements and never edited directly. Approvals sit on purchase orders and significant adjustments, where the risk is, without adding steps to routine receipts and issues.
Raw materials, bought-out components and finished goods across store, inspection, shop floor and finished-goods locations — each with its own balance.
Suppliers, purchase orders and on-order quantity visible beside on-hand stock, so "did anyone already order this?" stops being a phone call.
Received material lands in inspection, not directly into usable stock, so quantity and quality decisions are separate and both recorded.
Consumption is captured once, at the source, on the floor — replacing paper slips typed in days later.
Shortage detection moves from the workbench to the purchasing desk, where there is still time to act.
Every adjustment carries a reason, an approver and a permanent record. Append-only history means reconciliation is a check, not an investigation.
The core outcome: stock numbers people can act on without checking them first. When the ledger is trusted, purchasing, production planning and customer commitments can all move faster — because the question of whether the number is right has already been answered by design.
Items, locations, documents and posting rules were defined before any screen was drawn.
Integrity is enforced at the database level, not in a validation function somebody can forget to call.
A storekeeper issuing material mid-shift needs a different screen from a manager reading a report.
New items, locations, users and suppliers are configuration, not redevelopment. The modular API leaves a clear path to planning or accounting integration.