AI Development Cost Guide
Software estimates assume the build is the whole project. AI budgets that assume the same thing run out mid-way, because building is only the middle phase. Before it comes a feasibility question that can fail outright. After it comes a running cost that never stops. This guide separates the three so you can budget each one honestly instead of pricing a single feature.
AI spend splits into three different phases.
A feature build has one phase: it either ships or it does not. AI work has three, and each behaves differently. Proving an idea works comes first and can fail outright. Building the delivered system comes next, once feasibility is settled. Running the model in production comes last, and that cost continues for as long as the system stays live. Pricing the whole effort as one lump ignores which phase is driving the number.
Phase oneFeasibility, and it can fail
A short piece of work that tests whether the idea holds against real data. Ending it early when it does not work is the goal, not a failure.
Phase twoThe delivery build
Once feasibility clears, this is the scoped, fixed-shape project most estimates already know how to price using ordinary software methods.
Phase threeEvaluation, ongoing rather than one-off
Testing does not stop at launch. New inputs keep arriving, and someone has to keep checking the system still behaves as intended.
Phase fourRunning inference
Every call to the model carries a cost, and that cost keeps arriving for as long as the system serves real users.
Feasibility work should be cheap enough to abandon.
Committing to a full build before anyone tests the idea against real data is the most common way AI budgets go wrong. A short, bounded piece of work should answer one question: can this actually work well enough to be worth building. If the answer is no, the right outcome is stopping there, having spent very little to learn it.
01Step oneSet the failure line first
Decide in advance what result would mean the idea does not work. Without that line, a struggling experiment tends to keep receiving funding anyway.
02Step twoBound the exploration in time
Give the feasibility phase a fixed window rather than an open brief. An open-ended experiment rarely produces a clear answer either way.
03Step threeTest against your own data
A demonstration built on clean sample data proves very little. The real question is how the approach behaves against the messy data you actually have.
04Step fourDecide who signs off the result
Someone independent of the excitement should judge whether feasibility was actually met, not the team that wants to keep building.
Evaluation is ongoing work, not a pre-launch checkbox.
Conventional software testing proves a feature works and then moves on. An AI system keeps producing new outputs against inputs nobody anticipated, so testing has to continue for as long as the system runs. Budgeting evaluation as a one-time task before launch is the second most common way these projects are underpriced, right behind treating the whole effort as a single feature.
Building a test set that reflects reality
A useful test set grows from real requests and real failures, not from a handful of cases written before anyone used the system.
Watching for drift after launch
A model that performed well at launch can degrade as the inputs it sees shift away from what it was checked against.
Handling the cases nobody predicted
Users find inputs no test set anticipated. Someone has to review those cases and decide whether the system needs adjustment.
Owning the review cadence
Evaluation needs a named owner and a standing schedule, or it quietly stops happening once the initial excitement fades.
The build ends; the running cost does not.
Delivery is a project with a start and an end. Running the model in production is not a project at all, because every call it answers carries a cost that recurs for as long as the system is live. A system that is cheap to build can still be expensive to operate at scale, and the two figures answer completely different questions.
Cost per call, not cost per project
The number that matters after launch is what one call to the model costs, multiplied by how often the system is actually used.
What drives the per-call figure
The size of the model, the length of what it reads and writes, and how often a request needs to run more than once.
Forecasting against expected volume
A per-call figure means little without a volume estimate behind it. Forecast usage honestly before committing to an operating model.
Building in a ceiling
Without a cap on usage or spend, a popular feature can turn a modest running cost into a serious one almost overnight.
Estimate the three phases separately, not the whole effort at once.
A single figure for an AI project hides which phase is driving it. Pricing feasibility, delivery and running cost as separate lines produces a number you can actually defend, and it shows exactly where a budget is most likely to move.
01Step oneFund feasibility like an experiment
Give it a fixed budget and a clear question to answer, and treat a negative result as a successful, cheap outcome.
02Step twoScope the delivery build once feasibility clears
Only once the idea has proven itself does an ordinary, fixed-shape project estimate become meaningful.
03Step threePrice evaluation as a standing line
Add a recurring cost for review and testing rather than folding it into the build and hoping it disappears after launch.
04Step fourModel the running cost against volume
Multiply the per-call figure by a realistic usage forecast, not the smallest number that makes the project look affordable.
Plenty of problems do not need a custom-trained system.
Guides that sell AI work tend to argue for the bespoke answer, because that answer is the larger project. It is often the wrong one. An existing model, used well, solves a large share of real problems without the feasibility risk or the ongoing maintenance a custom system carries.
The task is narrow and well understood
A well-defined task with plenty of existing examples rarely needs research work before it can be built.
An existing model already clears the bar
If a general-purpose model already performs well enough on your task, custom work adds cost without adding capability.
You lack the data to justify custom work
Custom systems need volumes of relevant data most teams do not have. Without it, the feasibility phase is likely to fail anyway.
The risk of over-building
A bespoke system nobody has the skills to maintain becomes a liability the moment the team that built it moves on.
A single number here would hide the phase it came from.
This guide states no figure on purpose. A cost that has not separated feasibility, delivery and running spend is not measuring one thing, so naming it would look precise while telling you very little about your own project.
What a real estimate requires
Someone has to see the actual task, the available data and the expected volume before any figure means anything.
Where AI work sits inside a wider build
AI features usually attach to an existing product, and the surrounding engineering shapes the total cost as much as the model does.
What drives the running-cost side
Volume, model size and call frequency together set the operating figure, and a calculator is a faster starting point than a guess.
Turn the three-phase model into a plan for your build.
The phase-based view here gets you a number you can defend internally. Turning it into a committed plan needs someone to look at your actual task, your data and your expected volume together.
Scope the feasibility phase
A short, priced piece of work can test your idea against real data before any larger commitment is made.
See how AI work fits a wider build
Most AI features sit inside a larger product, and the engineering around the model often decides whether it ships at all.
Read the neighbouring guides
The same phase-based thinking applies to other cost questions, with the variables shifting between them.
Asked before an AI budget gets approved.
01Why can't a vendor just quote a fixed price upfront?
A fixed price assumes the phases are already known, and for AI work the first phase is finding out whether the idea works at all. Quoting delivery before feasibility is settled prices a risk nobody has measured yet.
02What does a feasibility phase actually produce?
A clear answer to one question: does the approach work well enough against real data to justify building it. The output is a decision, not a finished feature, and a negative result is still a useful one.
03Does evaluation work ever come to an end?
No, and treating it as a pre-launch task is a common way these budgets fall short. New inputs keep arriving after launch, so someone has to keep checking the system still behaves as intended.
04Why does the running cost matter more than the build cost?
The build is a one-time project with a fixed price. The running cost recurs for every call the system answers, for as long as it stays live, so it can outweigh the build within a short period.
05Should we build a custom model or use an existing one?
Start with an existing model unless your task is genuinely unusual or your data volume justifies custom work. Most problems do not clear that bar, and starting simpler avoids the feasibility risk entirely.
06How do we stop exploration work from running forever?
Give the feasibility phase a fixed budget and a clear failure line before it starts. Without both, an experiment that is not working tends to keep receiving funding anyway.
07What happens to the running cost as usage grows?
It grows with it, because the cost is tied to each call rather than to the project. Forecasting realistic volume before committing avoids an unpleasant surprise once the feature becomes popular.
08Who should own evaluation after the system ships?
A named owner with a standing schedule, not whoever happened to build the feature. Evaluation that has no owner quietly stops happening once the initial launch attention moves elsewhere.