Where the money actually goes
The intuition most teams start with is that an AI product is mostly AI. In delivery it usually is not. A representative split for an MVP in the band above:
| Work | Typical share | What it covers |
|---|---|---|
| Data preparation and retrieval | Largest single block | Ingestion, cleaning, chunking, embedding, permissioning. Grows fastest when the source data is messy |
| Product surface | Substantial | Frontend, auth, multi-tenancy, billing, admin. An AI SaaS is still a SaaS and needs all of it |
| Integrations | Highly variable | ERP, CRM, identity, storage, whatever the answer has to reach. The main driver of variance |
| The AI pipeline itself | Smaller than expected | Prompting, orchestration, tool use, model routing |
| Evaluation and quality | Small but non-optional | Scored test sets, hallucination checks, regression detection, monitoring |
| Infrastructure and deployment | Small | CI/CD, observability, cost alerting, model versioning |
The row worth defending in a budget conversation is the last-but-one. Evaluation has no demo attached to it, so it is the first thing cut — and it is the only thing standing between you and finding out from a customer that quality regressed three weeks ago.
The four things that inflate a quote
1. Data that is not what you think it is
The single most common cause of an AI project running over. Corpus quality decides the timeline more often than any architectural decision does, and almost nobody knows the true state of their own documents until someone tries to index them. Before committing to a scope, take a genuine random sample — not the tidy examples — and check formats, languages, duplication, and whether permissions can even be represented.
2. Integration count
Two integrations and eight integrations are different projects at the same feature count. Each external system brings its own auth model, rate limits, failure modes and undocumented behaviour, and none of that is visible from the requirements document.
3. Compliance scope arriving late
GDPR readiness is a design constraint, not a feature, and it is cheap when it is designed in and expensive when it is added. HIPAA-aligned architecture, data residency and audit logging are real additional scope. Discovering in week nine that the data cannot leave a jurisdiction is a schedule event, not a task.
4. Scope that is a demo rather than a product
An impressive prototype is days of work. The distance from prototype to something you can charge for — auth, tenancy, billing, error states, rate limiting, evaluation, support tooling — is where the budget goes. Both are legitimate things to build; the mistake is pricing one and expecting the other.
How to make the number smaller, honestly
- Cut integrations before you cut features. One integration done properly beats three done partially, and the saving is larger than the feature list suggests.
- Fix the data before the pipeline. Time spent making a corpus clean and permissioned pays back several times over in retrieval quality and in engineering hours.
- Start with retrieval, not training. Almost every product that thinks it needs a fine-tuned model needs retrieval — see RAG or fine-tuning for the test that tells you which you are looking at.
- Ship one workflow end to end. A narrow product that completes a real job is more valuable, and cheaper, than a broad one that half-completes several.
What a quote from us looks like
Managed delivery is quoted fixed-price after a discovery call, and the written scope comes back within 48 hours. The bands above are published on our pricing page alongside the rest, including what is deliberately not banded and why. For an example of what lands inside this range in practice — multilingual document processing, a custom retrieval architecture, ERP integration and an 87% reduction in manual processing — see the enterprise AI analytics case study.