How AI development is priced
There are four ways to buy the work, and the right one depends on how well defined the problem already is.
- Discovery and roadmap. A short, fixed fee engagement that audits your use cases, reviews your data and returns a costed plan. Priced and time boxed before it starts, so an audit cannot quietly become a project.
- Fixed scope build. Priced at the end of discovery and held for the life of the build, billed per milestone. Change requests are priced against the remaining milestones rather than added on.
- Dedicated team. Quoted per seat once the roadmap is known, on a rolling basis with seats added or removed as the work changes.
- Staff augmentation. Quoted per engineer, with your own leads setting priorities. There is no placement fee and the ramp is not billed as delivery.
Each model is described in full, including how notice and billing work, on the engagement models pages.
What actually drives the cost
Five things account for most of the difference between a modest engagement and one several times its size.
The state of your data
This is the largest single factor and the one discovered latest. Data that is already labelled, consistent and available at the moment a decision has to be made keeps a project small. Data spread across systems, labelled inconsistently, or missing at prediction time adds weeks before a model is trained at all.
How many systems the model has to reach
A model that answers questions in isolation is inexpensive. One that reads from your CRM, writes to your ticketing system and respects your permission model is not, because identity, latency budgets and failure behaviour each have to be designed rather than assumed.
Whether the outcome has to be measured
A demonstration needs to work once. A production system needs an evaluation set, an accuracy threshold agreed in advance, and monitoring that says when it drifts. That difference is usually around a third of the build, and it is the part most often missing from a cheaper quote.
Compliance and data residency
In healthcare, legal and financial work, PHI handling, audit trails and residency are architectural decisions rather than a review at the end. They add cost at the start and remove considerably more of it later.
Whether a model needs training at all
Most business problems are solved by grounding an existing model in your own content rather than training a new one. Training is occasionally the right answer and is always the more expensive one, which is why discovery tests the cheaper option first.
What sits outside the price
Two things are never bundled, and both are agreed in advance rather than discovered later.
- Cloud and model running costs. Inference, hosting and storage are yours, and we attribute them per request so the running bill is something you modelled rather than met.
- Third party licences. Any commercial data source or tool the solution depends on is named during discovery, before it becomes a dependency you cannot remove.
Why do AI development quotes vary so much?
Because most quotes are pricing different things. A quote for a demonstration and a quote for a system that runs unattended differ by the evaluation, the integration, the monitoring and the governance, and those are exactly what gets left out of the cheaper number. The gap usually appears in month four rather than at signature, which is why it is worth finding before.
What to ask before you sign anything
Five questions separate a quote you can rely on from one that will move.
- What accuracy threshold are you committing to, and measured against what set? A quote with no number here is pricing a demonstration.
- What happens when the model is slow, wrong or unavailable? Undefined failure behaviour is a cost deferred, not avoided.
- Who owns this after launch, and what does that cost? A system nobody maintains stops earning within a year.
- What is excluded? Running costs and licences should be named up front, not itemised later.
- What would make this price change? The honest answer is a short, specific list. A vague one means the risk is still yours.
How to spend less on AI development
The cheapest projects are the ones that decided what not to build.
- Start with discovery. A short engagement costs a fraction of a build and regularly ends by recommending against the thing originally asked for.
- Narrow the first use case. One workflow, one team, one measurable outcome. Breadth is what turns a project into a programme.
- Use an existing model before training one. Retrieval against your own content answers most of what people expect fine tuning to solve.
- Settle the data question first. If the signal is not in the data, no amount of model spend puts it there.
How we arrive at a price
We quote a fixed price at the end of discovery and hold it for the life of the build. We do not quote before discovery, because a number given without knowing the state of your data is a guess that somebody pays for later, and it is usually you. Where discovery concludes that building is not worth it, that is what the roadmap says and you keep the document.
Costs for specific kinds of work
- What AI chatbot development costs: what a grounded assistant involves, and what a cheaper quote tends to leave out.
- How IT staff augmentation is priced: what sets a rate, and how to compare two of them fairly.
Decisions worth settling first
- AI glossary: plain definitions of the terms these decisions turn on.
- Build vs buy AI: whether this needs building at all.
- AI agency vs in-house team: who should build it.
- RAG vs fine-tuning: which approach the problem actually calls for.