The demonstration took two weeks. The remaining nine tenths is this service

AI prototypes are unusually easy to build and unusually hard to finish. What separates them from a system is not model quality: it is evaluation, retrieval that actually finds the right thing, cost and latency inside a budget, permissions, failure behaviour, and the ability to change something without silently breaking it.

  • Software in production against real data. With real permissions, real volumes and the exceptions that were absent from the demonstration.
  • An evaluation harness. A test suite for a probabilistic system, so a change can be judged rather than felt, and a regression is caught before a user finds it.
  • Cost and latency inside a budget. Measured per request and per task, with the levers documented rather than discovered during the first large invoice.
  • Code you own. In your repositories, deployable by your team, with the model behind an interface so you are not married to one provider.
Talk to us about this

What is delivered

  • Evaluation harness

    Real cases with known answers, scored automatically, run on every change. The single highest-value artefact in an AI codebase and the one most projects skip.

  • Retrieval that works

    Chunking, indexing and ranking tuned against your actual documents, with retrieval quality measured separately from answer quality — because most bad answers are retrieval failures wearing a model costume.

  • Guardrails and validation

    Structured output validation, refusal behaviour, injection resistance by architecture, and the rules about what must never be generated.

  • Cost and latency engineering

    Model routing, caching, batching and prompt economy, with the numbers visible per feature so a product decision can account for them.

  • Observability

    Traces, decision logs and quality metrics designed for a system that degrades quietly rather than crashing loudly.

  • Deployment and handover

    CI, environments, secrets and runbooks on your infrastructure, documented well enough for your team to take it over.

How it runs

  1. 01

    Harness first

    Evaluation before features. Without it, every later change is a guess, and the project's speed collapses around month three.

  2. 02

    Thin slice to production

    One complete path end to end, deployed, in front of a small group. Everything unknown surfaces here and it surfaces cheaply.

  3. 03

    Widen

    More cases, more users, more automation, each step justified by what the evaluation shows rather than by the plan.

  4. 04

    Hand over

    Your engineers pairing throughout, documentation written during the work, and our involvement declining on a written schedule.

A good fit when

  • A prototype works and nobody knows what it would take to make it real.
  • An AI feature is live and its quality is unmeasured, so nobody dares change it.
  • Costs or latency are unacceptable and the levers are not understood.
  • You need the system on your own infrastructure with your own data rules.

Not the right service when

  • The use case has not been validated with users. Build the prototype first — it is cheap and it answers a different question.
  • You want a proof of concept for a board meeting. That is a legitimate purchase and it is not this.
  • The data required does not exist yet. Data engineering comes first; no amount of application work compensates.

Frequently asked questions

Which stack do you build on?
Whatever suits your constraints: your existing cloud, an open-source stack, or a mixture. The one constant is that the model sits behind an interface, because providers change and a system married to one is a system with a hidden dependency.
How do you test something that is not deterministic?
With an evaluation set of real cases and known good answers, scored automatically, plus regression checks on the awkward cases. It is not unit testing and it does the same job: telling you whether a change made things better or worse before your users do.
How do you keep costs predictable?
By measuring per request from the first week, routing easy work to smaller models, caching aggressively and treating prompt length as a cost. Most large bills come from one unexamined code path rather than from the product being expensive.
Can you take over an existing codebase?
Yes, and the first thing we usually build is the evaluation harness, because without it any change to an inherited AI system is a gamble. That is typically week one, and it usually reveals the actual problem.
Do we get the code?
It is in your repositories from the first commit. Deployment is on your infrastructure, secrets are yours, and the handover terms are agreed before the work starts.

Keep reading

Other services