Ask ten agencies what an AI project costs and you’ll get ten different non-answers. That’s not evasion — AI and ML work genuinely doesn’t compress into a single number the way a website or an MVP does, because the biggest cost driver is something you don’t know yet: whether the model is actually good enough for the job.

Here’s a straight explanation of why, and what a sensible process actually costs.

Why there’s no rate card

A booking form and an AI-assisted document review pipeline can both be called “an AI feature,” and their costs can differ by a factor of ten. What decides it isn’t lines of code — it’s:

  • Whether the underlying task is even a good fit for AI. Some workflows look automatable and aren’t, once failure cost and edge cases are accounted for.
  • Data readiness. Clean, accessible, well-labelled data is cheap to build on. Data scattered across systems with no clear ownership adds discovery and cleanup work before any model gets touched.
  • Acceptable failure cost. A tool that drafts an internal summary can tolerate more error than one that makes a compliance or financial decision. Higher failure cost means more evaluation, human review, and guardrail work.
  • Integration depth. A standalone assistant is simpler than a model embedded in an existing workflow with permissions, audit trails, and legacy system connections.

Because of this, credible AI providers scope in two stages rather than quoting a fixed project price upfront.

Stage one: validation

Before committing serious budget, the sane first step is a bounded validation phase — similar in shape and cost to a standalone discovery engagement, not an open-ended research project. It should answer, on a fixed budget and timeline:

  • Is this task actually a good fit for AI, given the failure cost involved?
  • Is the data available and clean enough to build on?
  • What would a task-specific evaluation set and acceptable failure boundary look like?

If the answer is no, you’ve spent a bounded, small amount to avoid an open-ended one. That’s the point of treating validation as its own priced step rather than folding it into a full build quote nobody can actually stand behind.

Stage two: build and integrate

Once validated, the build phase is scoped against the real inputs: which model or provider, how much retrieval and grounding infrastructure is needed, how deep the integration goes, and how much human review the workflow requires in production.

As a rough market orientation — not a quote — narrow, well-scoped AI features (a grounded search or summarisation tool over existing content) tend to sit in the low tens of thousands. Workflow automation with multiple integrations, evaluation infrastructure, and human-in-the-loop review climbs from there, and regulated or high-failure-cost use cases climb further still because of the validation and control work involved.

What should be included regardless of size

  • Use-case validation before build commitment, not after.
  • An evaluation set and defined failure boundaries, agreed before anyone calls a demo “production-ready.”
  • Human controls and fallbacks for outputs below the quality threshold, not just a raw model call.
  • Cost and quality monitoring once it’s live, since model behaviour and usage patterns both drift over time.

A quote missing the first two items is usually cheaper for a reason — it’s pricing a demo, not a production feature.

Questions worth asking before you commit budget

  • What specifically will the validation phase tell us, and what happens if the answer is “this isn’t a good fit”?
  • What’s the evaluation set, and who defines what “good enough” means?
  • Can this run inside our own cloud and data boundary, using our access controls?
  • What’s the fallback when the model gets it wrong in production?
  • How is ongoing cost monitored once real usage starts?

If you have a workflow you think AI could improve, book a strategy call and we’ll tell you honestly whether it’s a good validation candidate — see the full approach on the AI and Automation service page.