How to estimate an AI app project without guessing

AI features break the estimating habits that work fine for ordinary software, because the part everyone focuses on — the model call — is usually the cheapest thing in the build. This is how we separate the predictable work from the genuinely uncertain work, and put a range on each.

Rohan SahuFounder & CEO, SCS SoftwaresPublished 23 August 20269 min read

What this is based on: We build our own estimator: the questionnaire at /project-analysis takes a project description and produces an indicative team, effort, cost and timeline range. Everything below comes from making that tool produce numbers we are willing to defend, and from the client conversations that followed when a number turned out to be wrong.

Why AI estimates go wrong more often than ordinary ones

A conventional feature can be estimated because you can decide, in advance, whether it is finished. A login screen either accepts the right password and rejects the wrong one, or it does not. You can write that test before you write the code, and the moment it passes, the work is done.

A model-backed feature has no such line. "The assistant answers customer questions about our returns policy" is not a pass/fail statement — it is a quality statement, and quality statements are open-ended by nature. The first version works on the ten questions someone thought of. The tenth version works on the four hundred a real customer base produces. Nothing about the second number is visible from the first.

This is why AI projects overrun in a distinctive way. The build finishes roughly on time and then the project does not end, because "it mostly works" is not the same as "we can put this in front of customers", and nobody agreed in advance where that boundary sat.

The fix is not a better guess. It is deciding, before the estimate exists, what "good enough to launch" means in terms someone can check.

Split the project into predictable and uncertain work first

Before estimating anything, we cut a proposed AI project into two piles. The first pile is ordinary software that happens to sit next to a model. The second pile is the part whose cost depends on quality you cannot specify up front.

The first pile is almost always much larger than clients expect, and it estimates exactly like any other software, because it is any other software.

Predictable: authentication, roles and permissions, the admin interface, the database schema, file upload and storage, billing, the mobile or web client, notifications, deployment, monitoring.
Predictable: the integration plumbing around the model — the queue, the retry logic, the timeout handling, the audit log of what was sent and what came back.
Predictable: getting a model to respond at all. Wiring an LLM into an application is a day or two of work, not a phase.
Uncertain: how many iterations it takes before the output is good enough to show a customer without someone checking it first.
Uncertain: how much of your own content has to be cleaned, chunked and structured before retrieval returns the right passage instead of a plausible neighbouring one.
Uncertain: how many edge cases only appear once real users, rather than the team, are typing the inputs.

A useful rule of thumb from our own projects: in a first AI build, the model-facing work is usually the smaller share of total effort, and the surrounding application is the larger. If an estimate is mostly "AI development", something has been missed.

Estimate the predictable part the ordinary way

For the first pile, nothing about AI changes the method. Break the work into features, size each one against something the team has built before, and add the integration and testing time that always gets left out.

What matters far more than the sizing technique is the completeness of the list. Most software estimates are wrong not because a feature was mis-sized but because a feature was missing — and the ones that go missing are consistently the same ones.

Data migration from whatever the client uses today. Almost always underestimated, and almost never in the brief.
The admin side. Someone has to be able to correct, refund, re-run, disable and export. That is a second application.
Third-party integration behaviour when the third party is slow, down or has changed its API.
Release engineering: environments, secrets handling, database migrations, rollback.
App store review cycles, which belong to Apple and Google and do not respond to a project plan.

Estimate the uncertain part as iterations, not as features

The second pile cannot be sized as a feature, because the feature is "it works well enough". So we do not size it as a feature. We size it as a number of evaluation-and-improvement cycles, and we agree what one cycle contains.

A cycle, for us, is: assemble a test set of real inputs, run the current version against it, have a person judge the outputs, identify the dominant failure mode, change one thing to address it, and re-run. Each cycle has a knowable cost. What is unknown is how many you need.

That converts an unanswerable question into an answerable one. Instead of "how much will the AI cost", the question becomes "how many cycles is this worth", which a client can actually make a commercial decision about.

Build the test set before the first cycle, from real examples the client already has. Twenty real customer questions beat two hundred invented ones.
Decide what counts as a pass before you look at any output. Judging quality after seeing the answer is how teams talk themselves into shipping.
Fix a cycle budget at the start — a number of cycles the estimate covers — and treat exceeding it as a conversation, not an overrun.
Track which failure mode each cycle addressed. When two consecutive cycles chase the same one, the problem is usually the data or the scope, not the model.

This is also the honest answer to "can you guarantee accuracy". No, and neither can anyone else. What can be committed to is a measurement method, a review step and a number of improvement cycles.

The running costs almost every first estimate omits

An AI feature has an ongoing bill that conventional software does not, and it scales with usage rather than sitting flat. Leaving it out of the estimate produces a number that is right for the build and wrong for the year.

Per-request model cost, which depends on how much context you send — and the amount of context sent is a design decision, not a fixed property.
Retrieval infrastructure: the vector store or search index, plus the job that keeps it in sync when the source content changes.
For voice: speech-to-text and text-to-speech are billed per minute, separately from the model, and usually dominate the cost of a call.
Human review time, if the design requires a person to approve output before a customer sees it. This is a staffing cost, not a software cost, and it is often the largest line.
Re-testing after a provider updates a model. The behaviour you validated is not guaranteed to survive a version change.

We model these as a monthly range at a stated usage level, and we state the usage level. A running-cost figure without the assumed volume attached to it means nothing.

Produce a range, and say what would move it

A single number is a false claim. Everyone involved knows the project will not cost exactly that, so the number is quietly treated as fiction by both sides — which is worse than a range, because nobody agrees on which direction the fiction leans.

We give a low and a high, and then we do the part that actually helps: we name the specific unknowns that decide where inside the range the project lands, and what each is worth.

"If your product data is already structured, the retrieval work is at the low end. If it is PDFs and scanned documents, it is at the high end."
"If a human reviews every output before it is sent, the accuracy work shrinks. If it goes straight to the customer, it grows."
"If you need this in three languages rather than one, the evaluation work multiplies, not the build work."
"If the integration target has a documented API, this is small. If we are automating a screen, it is not."

This is also what makes an estimate reviewable. A client cannot sanity-check a total, but they can absolutely tell you whether their product data is structured.

What our own estimator does, and what it deliberately does not

The tool at /project-analysis applies the split above. It asks about the application around the AI, not just the AI: platforms, user roles, integrations, data sources, whether an existing system is being replaced, and who reviews the output. From those answers it produces an indicative team composition, an effort range, a cost range and a timeline range.

It is deliberately an estimate and not a quotation, and it says so on the page. It has not seen your codebase, your data, your third-party contracts or your compliance requirements, and any of those can move a number substantially. It is meant to replace a blank page, not a scoping conversation.

It also does not produce a single number, for the reason in the previous section, and it will not tell you a project is cheaper than we believe it to be in order to look competitive.

The short version

If you are about to estimate an AI project — ours or anyone else’s — these are the questions that decide whether the estimate is worth anything.

Has the work been split into ordinary software and quality-dependent work, and is the ordinary software the larger share?
Is there a written definition of "good enough to launch" that someone other than the author could check?
Is there a test set of real inputs, assembled before the first build?
Is the uncertain work priced as a number of evaluation cycles rather than as a feature?
Are running costs included, with the assumed usage volume stated?
Is the output a range, with the specific unknowns that move it named?
Is it clear who reviews model output before a customer sees it, and is their time in the budget?

Questions this raises

Can you give a fixed price for an AI project?

For the predictable half — the application around the model — yes, once scope is written down. For the quality-dependent half we fix the cost of an agreed number of evaluation-and-improvement cycles rather than fixing an accuracy level, because no one can honestly commit to an accuracy level in advance. That keeps the commercial risk bounded on both sides without either party pretending to certainty.

Why is the AI part often the cheapest part of the build?

Because calling a model is a small amount of code. What surrounds it is not: authentication, permissions, an admin interface, data storage, integrations, error handling, audit logging, deployment and monitoring are all ordinary software, and together they are usually the larger share of the effort. Estimates that go badly wrong are typically the ones that priced the model call and treated the rest as detail.

How long should the evaluation cycles take?

A cycle is short by design — assemble inputs, run, judge, change one thing, re-run. The variable is how many you need, not how long each takes, and that depends mostly on how messy the source data is and how narrow the task is. A tightly scoped assistant answering questions about well-structured content converges quickly. An open-ended one over mixed documents does not.

What makes an AI estimate move to the high end of its range?

In our experience: unstructured source data such as scanned documents; a requirement that output reaches customers without human review; more than one language; integration with a system that has no documented API; and a definition of success that is still being decided while the build is running. Any one of these is manageable. Three at once is a different project from the one that was estimated.

Should running costs really be in the build estimate?

They should be quoted alongside it, with the assumed monthly usage stated. Model, speech and retrieval costs scale with use, so a figure without a volume attached is meaningless. If human review is part of the design, that staffing time belongs in the same picture — it is frequently the largest ongoing line, and it is the one most often discovered after launch.

Is the estimate from your online tool binding?

No. It is indicative, and the page says so. It has not seen your codebase, your data, your existing contracts or your compliance obligations, and each of those can move the number. It exists to give you a defensible starting range and a structured description of your own project before you talk to anyone — including us.

Put a range on your own project

The estimator asks the questions in this article and returns an indicative team, effort, cost and timeline range. It is an estimate, not a quotation, and there is no signup.

Get a free project estimate Start an AI consultation Contact the team