What does an AI-powered web application really cost?

Custom AI development is quoted anywhere from $5,000 to $150,000 in 2026, and the range is wide because "AI web application" describes everything from a smart form to a full operational platform. This is how to work out which one you actually need — and what it should cost.

Three tiers, honestly described

A focused tool. One job, done well: a document analyser, an intake assistant, a search interface over your own content. Days of work, not months, because the scope is genuinely small. This should cost low thousands, and if someone quotes you $40,000 for it, they are pricing your budget rather than the work.

An operational application. Multiple users, roles and permissions, data that persists, integration with one or two systems you already run. This is most real business software. Mid five figures is a fair market price; the honest version of this is what we scope at $7,500 for an SMB.

A platform. Many workflows, many user types, deep integration, compliance obligations, audit trails. This is a genuine six-figure programme and anyone quoting it at $10,000 does not understand what they have agreed to.

What makes the number move

Not the AI. The models are commodity and getting cheaper. What moves the number is everything around them: how many systems it must talk to, how many user roles need different permissions, whether the data is clean, whether decisions need an audit trail, and how much of your existing process has to be respected rather than replaced.

A useful test when reading any quote: ask the vendor which line item would shrink most if you cut one feature. If they cannot answer immediately, they have not scoped it — they have estimated it.

Fixed price versus time and materials

Open-ended time and materials on an AI project is a blank cheque, because nobody on either side knows when "done" is. Fixed price forces the honest conversation up front: what exactly ships, what explicitly does not, and what happens if it takes longer than planned. The answer to that last question should be "that is our problem, not yours" — in writing.

What to insist on regardless of who builds it

• Your cloud, your accounts. The application runs in infrastructure you control, so leaving is a decision rather than a rebuild.
• The repository in your name from day one, not on handover.
• An evaluation set built from your real cases before the build starts, so "it works" is measurable rather than a demo.
• A named human who can override anything the system decides, with the escalation path written down.