The demo is the easy part.
A convincing AI prototype takes a weekend. What takes the other three months is everything that separates a demo from a feature: knowing whether a prompt change made things better or worse, keeping the cost per request from tripling silently, and deciding what happens on the ten percent of inputs the model gets wrong. We build the second part first, because the first part is not the risk.
This is for you if
- You have a prototype everyone loved and nobody can decide is good enough to ship
- Each prompt change fixes one thing and quietly breaks another, and nobody can prove which
- Your token bill is growing faster than your usage and no one can explain the gap
- The feature has to be right often enough that 'usually' is not an acceptable answer
It isn't, if
- You want a chatbot on your marketing site. That is a smaller job and there are products that do it well; we will point you at one.
- You want to train a foundation model. We build on models, we do not pretrain them, and anyone telling a mid-market business otherwise is selling something.
- There is no way to tell a good answer from a bad one, even by hand. If a human cannot grade it, an evaluation harness cannot either, and neither can you.
What actually happens.
- 01
Decide what correct means
Before any building: a set of real inputs with the answers we would accept. This becomes the evaluation set, and without it every later decision is a matter of opinion.
- 02
Retrieval, prompting and tools, together
The three are one design problem. Bolting retrieval onto a prompt that was written without it is how you get a system that cites confidently and wrongly.
- 03
Budgets in code
Cost and latency ceilings enforced at the call site, with caching and model routing behind them. A cheaper model handling the easy eighty percent is usually the single biggest saving available.
- 04
Guardrails and the human path
What happens when confidence is low, when the input is hostile, and when the answer must not be wrong. Human review is designed in at the start, because retrofitting it means redesigning the interface.
What you get
- Retrieval, prompting and tool-use designed together rather than bolted on
- An evaluation harness, so a prompt change is a measured change
- Cost and latency budgets enforced in code, not discovered on the invoice
- Fallbacks and human review paths for the answers that must not be wrong
Built with
- TypeScript
- Python
- Anthropic
- OpenAI
- pgvector
The outcome
A feature you can put in front of customers, not a demo that works on your laptop.
Products with a model at the centre of them, built with the evaluation and guardrails that keep them shippable.
Get a free consultationScope and a fixed price before anything is committed. No obligation to proceed.
No dark periods. No surprise invoices.
A structured engagement from the first call to launch, so you always know what is happening and what it costs.
Week 1 · Discovery
Scope & fixed price
Then, every week after
A working demo.
The ones people actually ask.
Which model do you use?
Whichever wins on your evaluation set at an acceptable cost, and often more than one: a small model for routing and easy cases, a larger one for the rest. Building against an abstraction means switching later is a config change rather than a rewrite.
Will our data be used to train someone's model?
Not on the enterprise API tiers we build against, and we configure it that way explicitly rather than relying on a default. Where data cannot leave your environment at all, we will say whether self-hosting is realistic for your case before you commit.
How do you stop it making things up?
You reduce it, you do not eliminate it. Grounding answers in retrieved sources, showing the citation, refusing rather than guessing when retrieval is empty, and routing low-confidence cases to a person. Anyone promising zero is describing a product they have not measured.
What does this cost to run?
We model it before building and put a ceiling in code. The estimate covers tokens, vector storage and the infrastructure around it, and it is part of the proposal rather than a discovery you make in month two.
Often bought alongside
Custom App Development
Internal software for the work your business actually does: portals, back offices, and the operations tools no vendor sells.
MVP & POC Development
The smallest version of the idea that can still be judged, built in weeks and instrumented to tell you something.
CMS Development
Headless content platforms your marketing team can run at speed, without a ticket and without breaking the layout.
All services · Working on your own career instead? Career services for engineers
What is the most expensive thing your team still does by hand?
Tell us, and we'll tell you honestly whether software can fix it, and roughly what it would cost. No pitch deck.