Cost
AI development cost in India.
Everyone answers this with "it depends, contact us". It does depend, but on things you can work out before you speak to anybody: how many systems have to be touched, how much of your data needs repairing, and whether the finished thing has to run without a person watching it.
The short answer, in bands
Scoping diagnostics start in the low lakhs. Production builds are usually a multiple of that, and the multiplier is set almost entirely by integration surface.
Three bands cover most of what we are asked to build. Each carries an assumption, and the assumption is the part that matters.
Low lakhs. A scoping diagnostic, or a contained proof of concept against data you already hold in one place. One system touched, no production traffic. Assumes nobody depends on the output yet.
Mid lakhs. A pilot real users touch. Two or three systems integrated, an evaluation harness, enough observability to see what is happening, a human in the loop for cases the system should not decide alone. Assumes it is allowed to fail visibly.
Tens of lakhs. Something that runs unattended against production traffic. Half a dozen or more integration points, data work that is no longer optional, audit trails, rollback, a named person on call. Assumes a wrong answer costs money or attracts a regulator.
These are not quotes. They are the bands we find ourselves in, published so you can sanity-check what you are told elsewhere. If your problem sounds like the third band and has been priced like the first, somebody has misunderstood the work.
Integration surface is the dominant term
The number of systems your AI has to touch predicts cost better than anything else, including the difficulty of the AI.
People expect the model to be the expensive part. It is not. Calling a model is a few lines of code and a metered bill. What consumes months is everything the model has to reach: the CRM whose API returns a different shape depending on which decade a record was created in, the ERP that only exposes a nightly export, the database where the same customer exists three times under two spellings.
Systems are not additive. Each brings its own authentication, failure modes, definition of a duplicate and internal owner whose sign-off you need. Two systems is a straightforward build. Six is a different project, and the price difference is surface, not ambition.
So before asking anyone for a price, list every system that has to be read from or written to, with its owner and whether it has an API. That list is most of the estimate. Bring it to a scoping call and the conversation starts weeks ahead.
Evaluation and observability are a line item
If a proposal has a line for the model and no line for measuring whether it is right, you are being sold a demo.
An AI system is the only kind of software that can be broken and still look like it is working. A conventional bug throws an error. A retrieval system that has quietly stopped finding the right passage returns a fluent, confident, wrong answer, and it keeps doing that until something measures it.
That something has to be built: an evaluation set drawn from questions your business really receives, scored against answers your subject-matter people agree are correct, run on every change. Plus tracing in production — what was retrieved, what was sent, what came back, what it cost.
Budget it as a proportion of the build. It is the difference between a system you can improve and one you can only replace, and it is the first thing a cheaper quote removes. It is also the core of how we approach RAG and LLM integration.
Data readiness: the work nobody budgets for
Almost every overrun we have seen began with an assumption that the data was ready. It usually is not, and finding out costs weeks.
"We have all the data" means something different to a business person and to an engineer. It usually means the data exists somewhere. Whether it is complete, current, consistently labelled, deduplicated, permissioned and structured to survive being chunked and indexed is a separate question, and it decides your timeline.
The examples are dull and expensive. PDFs that are scans rather than text. Three superseded versions of a policy in the same folder as the current one with nothing marking which is which, the fastest route to a system that confidently cites a rule withdrawn two years ago. Records with no reliable join key.
That is what operational data looks like. It means the honest sequence is to look at the data first and price the build second, which is why our first phase is a diagnostic. Where the repair is substantial it becomes its own phase, billed as data engineering for AI rather than buried in the model work.
Compliance is an architecture cost, not a legal one
DPDP and RBI residency requirements change what you build, not only what you sign. Designed in at the start they cost weeks. Retrofitted they cost months.
Three requirements are cheap early and expensive later. Consent recorded and revocable per purpose, read at request time rather than implied by the existence of a row. Deletion that reaches everywhere personal data ended up — the vector store, the cached embeddings, the conversation logs, the evaluation set somebody built from production traffic. And a record of what you process and why, emitted as you go, because reconstructing it afterwards is archaeology.
Alongside those, RBI's storage direction requires payment system data to be held only in India, which constrains where a model can be served from rather than merely where a database sits. Self-hosting inside your own boundary answers that, costs more and performs somewhat worse. There is more on this on our India engineering page.
Demo, pilot, unattended: where budgets die
A demo takes days. A pilot takes weeks. Something that runs unattended takes months, and the gap between the last two is where most AI budgets are lost.
A demo answers "could this work". Curated inputs, a friendly audience, an engineer able to intervene. Useful for deciding whether to proceed, worthless as a predictor of cost, because everything hard was excluded from it by construction.
A pilot answers "does this work for us". Real users, real edge cases arriving in the order reality supplies them rather than the order a slide deck does. This is where you find out that a large share of your inbound arrives as a photograph of a document.
Unattended operation answers "can we stop watching it", and that is a different engineering problem rather than a bigger version of the same one. Defined behaviour when a dependency is down. Idempotency, so a retry does not double-charge somebody. A confidence boundary above which the system acts and below which it escalates. Teams that budget for a pilot and then ask for unattended operation are asking for a second project, not the last ten per cent.
We price those as separate phases with explicit exit criteria, as set out on the engagement models page. If your goal is only feasibility, say so and we will scope a proof of concept and nothing more.
What it costs to keep running
Three ongoing lines: inference, retrieval infrastructure and human review. The third is the one nobody budgets and it is frequently the largest.
Inference scales with usage and is the line everyone thinks about. It is also the one most likely to fall, because providers keep competing and because a well-designed system sends the easy majority of requests to something small and reserves the expensive model for the hard residue. Routing everything to the largest available model is not more accurate. It is just more expensive.
Retrieval infrastructure scales with the size of your corpus rather than your traffic, which makes it easier to forecast. It grows when you add documents, not when you have a busy Monday.
Human review is the honest one. Any system where a mistake carries a cost has a band of cases it should escalate rather than decide, and someone has to look at those. As accuracy improves the band narrows. It does not close. We size all three during scoping, so the running cost is a number you agreed to rather than discovered.
What makes a quote a red flag
A fixed price before anyone has seen your data, and an accuracy figure promised in advance. Both are claims nobody is in a position to make.
A fixed price before anyone has looked at the data. Nobody can price document work without seeing the documents. A firm that quotes anyway has either padded the number, so you are paying for their uncertainty, or intends to renegotiate later.
An accuracy figure promised in advance. Accuracy is a property of a model measured against an evaluation set that does not exist yet. A percentage promised before that set is built is borrowed from somebody else's problem. The right answer at proposal stage is a method for finding out and a threshold below which the project has failed.
No line for evaluation or observability. The most reliable predictor of a system nobody can maintain.
A price per bot, per use case or per model. A template with your logo on it. Templates are fine for some problems, but you should know you are buying one.
Headcount sold as a substitute for judgement. A rate card and a bench, with the people who won the work handing you to people you never spoke to. The decisions that determine an AI outcome are made in the first three weeks by whoever understood the problem. We do not subcontract.
A discount that expires. If the price drops because you signed this month, it was never derived from the work.
Why an Indian firm costs less, and what that does not buy
The rate difference is structural rather than a discount on quality. It buys more engineering hours. It does not buy a shorter path.
Our engineer-hour rate is materially below a comparable London or New York firm. That is a difference in cost of living and salary structure, not a signal about seniority, and it is a large part of why roughly half our work comes from clients in the UK, the Gulf, Singapore and Australia.
It buys more hours against the same budget, best spent on the parts a squeezed budget deletes: evaluation built properly, observability from day one, the data repair that makes retrieval work at all. It does not buy a system that needs less measurement, integration that takes fewer weeks, or data that repairs itself. Anyone selling an Indian rate and a compressed timeline is selling the same corner cut twice. Our FAQ covers ownership, timelines and what happens if you want to stop.
When not to build at all
If an off-the-shelf tool solves your problem, we will name the tool and take no fee.
The cheapest AI project is the one you correctly decide not to run. A meaningful share of enquiries describe a problem a product already solves for a subscription: scheduling, transcription, standard document extraction, a deflection layer over a well-maintained knowledge base. Building a bespoke version spends mid-lakhs to reproduce something that already has a support team behind it.
The cases where building is right share a shape. Your process is genuinely unusual, or the integration surface is specific to systems only you run, or the data cannot leave your infrastructure, or the accuracy bar is set by a regulator. If none of those apply, buy the tool. For a read on which side of the line you are on, that is what an AI readiness assessment is for.
Questions about cost we get before the first call
How much does AI development cost in India?
Scoping diagnostics start in the low lakhs; production builds are usually a multiple of that depending on integration surface. The multiplier is set by how many systems have to be touched, how much of your data needs repairing, and whether the thing is allowed to fail in front of a customer. A firm quoting before it has seen your data is quoting a guess.
Why will you not give me a fixed price on the first call?
Because the honest answer varies by an order of magnitude, and covering that variance means padding the number. We fix the price of the first phase instead, which is small, and produce a scoped estimate for the rest from what that phase finds. You can stop after any phase and keep everything produced so far.
What is the smallest useful thing we can buy?
A scoping diagnostic: a fixed-scope phase in the low lakhs that looks at your actual data, names the integration points, builds a small evaluation set from questions your team really gets asked, and ends in a written recommendation. A fair share of those recommendations are that you should not build the thing.
What does an AI system cost to run once it is live?
Three lines. Model inference, which scales with usage and tends to fall as providers compete. Retrieval infrastructure, which scales with the size of your corpus rather than your traffic. And human review, which teams forget to budget and which is frequently the largest of the three. We size all three during scoping rather than after launch.
Is an Indian firm actually cheaper, and what does that buy?
Our engineer-hour rate is materially below a comparable London or New York firm, which is a structural difference in cost of living rather than a discount on quality. It buys more engineering hours for the same budget. It does not buy a shorter path, because the system still needs the same evaluation, observability and data work. We would rather you spent the difference on those than took it as a smaller invoice.
What should make me walk away from a quote?
A fixed price offered before anyone has looked at your data. An accuracy figure promised in advance, because nobody can know it until the evaluation set exists. A line item for the model and none for evaluation. A price expressed per bot or per use case, which usually means a template. And a discount that expires, which tells you the price was never derived from the work.
Do you ever tell clients not to build?
Yes, and it costs us projects. If an off-the-shelf tool solves your problem we will name the tool and take no fee. The scoping call is free and exists partly to establish whether the cheapest correct answer is a licence rather than an engagement.
Get a number attached to your actual problem
The scoping call is free. Bring the list of systems that would have to be touched and you will leave with a much sharper idea of the band you are in.