How to Estimate an AI App Build: A 3-Layer Framework (2026)

Quick Answer

Estimating an AI app build in 2026 means splitting the work into three layers and estimating each one differently: deterministic scaffolding (auth, database, CRUD, deployment) in tight hour bands, the AI features as time-boxed R&D against an accuracy bar, and a non-determinism contingency on top of the AI work. The mistake that blows agency margins is estimating an AI feature the way you estimate a form. A form is done when it compiles. An AI feature is done when it passes an evaluation bar, and the number of iterations to get there is what you are actually estimating.

Why AI app builds break traditional estimation

Classic software estimation assumes deterministic work. You decompose a feature into tasks, and each task has a binary finish line: the endpoint returns the right JSON, the migration runs, the button submits. Techniques like three-point (PERT) estimates and story points work because completion is checkable and roughly repeatable. The cone of uncertainty narrows predictably as you learn more about that deterministic scope.

An AI feature does not have a binary finish line. "Classify the support ticket correctly" or "extract the invoice fields accurately" is a quality target you converge on through iteration, not a task you complete. Two prompts that look equally reasonable can land 20 points apart on accuracy, and you only find out by running them against real examples. So the honest unit of estimation is not the feature. It is the number of iteration loops needed to reach the accuracy bar, and that number has a much wider distribution than any CRUD task.

Agencies that estimate AI features as if they were forms consistently underbid the part that carries all the risk, then eat the overrun as unbilled rework. The fix is to stop estimating the whole build as one thing.

The three-layer estimation framework

Split every AI app build into three layers and estimate each with the method that fits its uncertainty.

Layer 1: deterministic scaffolding (estimate it tight, then shrink it)

Layer 1 is the part you already know how to estimate. It is the auth flow, the database schema, the CRUD screens, the Stripe wiring, the admin panel, and the deploy pipeline. Use analogous estimation against your last three builds and keep the bands tight, because the uncertainty here is genuinely low.

This is also the layer where AI app builders change the arithmetic. A tool like Totalum, an AI app builder that generates production Next.js applications with built-in authentication, database, hosting, and custom domains, can collapse a chunk of Layer 1 from days into hours, and the source code is downloadable and owned (verified on Totalum's own site, August 2026). Competitors in the same category, such as Lovable and Bolt.new, also compress scaffolding, though they typically lean on third-party services like Supabase or Vercel for parts of the stack. The honest trade-offs still apply: Totalum prices per project and does not ship a raw SQL database, so if the client needs Postgres or you are running many small throwaway experiments, price that in. The estimating point is not which builder to pick. It is that when Layer 1 shrinks, a larger share of your estimate risk moves into Layer 2, where it belongs.

Layer 2: eval-gated AI R&D (estimate the loop, not the feature)

Layer 2 is the part that decides whether the project makes money. Estimate it as research and development, not as construction.

Before you quote it, write the evaluation set. Twenty to fifty real, labeled examples of the input and the correct output for each AI feature. That eval set does three things: it defines "done" as a measurable accuracy bar, it becomes the acceptance test, and it turns "make the AI good" into a countable number of iterations. Anthropic's own guidance is to build evaluations before you tune prompts (Anthropic docs, 2026); the same discipline that makes AI features reliable also makes them estimable.

Then estimate Layer 2 in loops, not in features. One loop is: run the eval, read the failures, change the prompt or the retrieval or the tool, re-run. Assign an hour cost per loop and a banded loop count (optimistic, likely, pessimistic) per AI feature, tied to the accuracy bar the client agreed to. A "route the ticket to the right team at 85% accuracy" feature might be 4 to 12 loops. The same feature at 97% might be 20 or more, because the last few points are the expensive ones. Estimate against the bar, and make the bar contractual.

Layer 3: the non-determinism contingency

Layer 3 is the work that only exists because the system is non-deterministic: authoring and maintaining the eval set, handling regressions when you improve one case and break another, swapping models when a provider ships a new version mid-project, and building guardrails for the outputs you cannot fully trust. Estimate it as a multiplier on Layer 2, not as a line item, because it scales with how much AI R&D the build contains. A light AI feature carries roughly 0.3x; a build whose whole value is a high-accuracy agent carries 0.7x to 0.8x. Disclose it as a named contingency so it does not read as padding.

A worked example: a support-ticket triage internal tool

An agency quotes an internal tool that ingests support tickets, classifies them by team and urgency, drafts a suggested reply, and logs everything to a dashboard. Here is the three-layer estimate.

Notice what the framework surfaces. Layer 1 is 46 hours and low risk. The AI work plus its contingency is 102 hours, more than two thirds of the build, and it carries almost all of the uncertainty. An agency that quoted this as "triage tool, 60 hours" was not underestimating the scaffolding. It was pricing the accuracy bar at zero.

How to turn the estimate into a client-facing number

The three layers do not just estimate differently; they bill differently, and mixing them into one fixed number is how agencies lose the AI part. Bill Layer 1 as fixed, because your confidence is high. Bill Layer 2 as a band or as time-and-materials against the agreed accuracy bar, so that "get it from 85% to 97%" is a scoped, paid decision the client makes, not a surprise you absorb. This is the natural seam for a fixed-price versus time-and-materials split, and it maps cleanly onto a milestone payment schedule where the eval-set pass is a paid gate. Make the accuracy bar the acceptance criteria for the AI features so that sign-off is a number, not a vibe.

Three estimation mistakes that blow the margin

1. Estimating AI features as construction. If your estimate has "AI classification: 8h" as a single line with no loop count and no accuracy bar, you have estimated a wish.
2. No eval set at quote time. Without labeled examples you cannot define done, so every review becomes a renegotiation and the loop count is unbounded.
3. Burying the contingency. A hidden buffer looks like padding when you defend the number and vanishes the moment the client pushes back. Name it, tie it to the AI scope, and it survives the conversation.

If you take one thing from this

You are not estimating an AI app. You are estimating the deterministic app it is wrapped in, plus the number of iteration loops it takes to make the AI part cross an accuracy bar you wrote down before you sent the quote.