The demo was easy. Production is the work.
A convincing language-model prototype takes an afternoon. Making one that is accurate enough, cheap enough and predictable enough to put in front of customers is an engineering problem, and it is the one we solve.
You might be here because
Situations we are brought in for
- A prototype impressed everyone internally and then failed on real user input.
- You cannot tell whether a prompt change made the system better or worse.
- Inference costs scale alarmingly with usage and nobody modelled it.
- Your team needs an AI feature and a clear-eyed view of what it can and cannot do.
What you get
Concrete deliverables, not a retainer with a hope attached
Feasibility assessment
An honest read on whether a model is the right tool here, what accuracy is realistically achievable, and what it will cost per request.
Evaluation harness
A graded dataset and automated scoring, so prompt and model changes are measured rather than argued about.
Retrieval and context pipelines
Ingestion, chunking, embedding and ranking built to be inspected and tuned — not a black box you cannot debug.
Production guardrails
Fallbacks, timeouts, cost ceilings, output validation and human escalation paths for when the model is wrong.
How it works
Four phases, each with an exit you control
- 01
Assess
We define the task precisely, establish what "good" means numerically, and check a non-model baseline first.
- 02
Measure
The evaluation harness is built before the feature. Without it, every subsequent decision is guesswork.
- 03
Build
Retrieval, prompting and orchestration, iterated against the evaluation set rather than against vibes.
- 04
Operate
Cost and quality monitoring in production, with alerting on drift and a documented path to swap models as they change.
Tools we reach for
Chosen per problem, not per fashion
This is what we use most for ai & applied ml. If your team is already productive in something else, we work in that instead — familiarity in your team beats preference in ours.
- TypeScript
- Python
- Anthropic API
- OpenAI API
- pgvector
- PostgreSQL
- LangGraph
Where this usually starts
Discovery Sprint
Discovery Sprint
Deciding what to build, before committing a budget to building it
A short, fixed-scope investigation that turns an ambiguous problem into a plan you could hand to any competent team — including one that is not us.
- Typical duration
- 1–2 weeks
- Commitment
- Fixed scope, fixed fee
Includes
- Stakeholder and user interviews
- Technical constraint and risk analysis
- Architecture options with trade-offs stated
- Scoped delivery plan with sequencing
- Written recommendation, including "do not build this" where that is the answer
You keep
- Findings document
- Annotated architecture diagram
- Prioritised delivery backlog
- Effort and risk assessment
Fee agreed after scoping. No commitment to that conversation.
Common questions
Will you tell us if AI is the wrong solution?
Yes, and we frequently do. A good deal of what gets scoped as an AI project is better served by search, a rules engine or fixing a data problem. Assessment is the first phase precisely so that answer arrives early and cheaply.
Can this run without sending our data to a third party?
Yes. Open-weight models running in your own infrastructure are a viable option for many tasks, with real trade-offs in capability and operational cost. We will lay those out against your actual requirements rather than assuming either answer.
How do you keep inference costs under control?
By modelling cost per request before building, routing easy cases to smaller models, caching aggressively where inputs repeat, and setting hard ceilings in code. Cost is a design constraint from the start, not a surprise on the first invoice.
Other services
Product engineering
Ship the product your roadmap keeps promising — designed, built and maintained.
Platform & infrastructure
Make deploys boring, incidents rare, and cloud spend explainable.
Legacy modernisation
Untangle the system nobody fully understands — without stopping the business.
Custom software
For the process no product on the market actually fits — built once, properly.
SaaS development
Multi-tenancy, billing and onboarding — the unglamorous parts that decide whether it scales.
Web applications
Serious applications in the browser — dashboards, editors, real-time tools that stay fast with real data.
API development
Interfaces other engineers have to live with — versioned, documented and hard to misuse.
Mobile apps
Apps that work on a bad connection, clear store review, and can be shipped weekly.
Next step
Think this is your problem?
Send us the shape of it. We will tell you whether it is a fit, what we would do first, and roughly what that takes.