Proof of work
The problems we have solved, and what we built to solve them.
Every project below started as something someone was already living with: an answer nobody could find, a failure nobody could see coming, a task everybody assumed took a whole evening. Read the first line of each one.
What we have built
9 builds, each one starting with a challenge worth solving.
Systems and sites we have designed, built and shipped. Each says what the situation was, what the thing actually is, and what changed afterwards. Some are products we built for ourselves, some were built for the businesses we work with, and names stay off the page until the owner has agreed in writing.
A multi-agent collaboration platform
ProblemOne AI model was doing every job in the product. Adding a capability meant rewriting the core, and if that model's vendor had a bad afternoon, the product failed in front of the people using it.
Specialised agents rather than one model doing everything. Agents are registered per task, take work orders off a queue, message each other while they work, and stream results back as each stage lands. An orchestrator sequences the stages, nothing reaches the user until it clears an acceptance gate, and each agent can run on a different model.
ValueA new capability is a new agent rather than a rewrite, the expensive model only touches the stages that need it, and when an agent is switched off or fails the product degrades to a simpler answer instead of failing in front of the user.
Retrieval that writes, not only answers
ProblemWriting a new examination paper meant an evening with a filing cabinet of old ones, and no way to show which paper a question had come from when somebody asked.
A system over a bank of past examination papers that finds the ones matching a target topic and difficulty, then drafts a fresh paper in the same style, keeping the sources attached so a teacher can check every question against the paper it came from.
ValueWriting a new paper stops being an evening with a filing cabinet and becomes a request and a proofread, with the evidence to defend any question in it.
Infrastructure that warns before it fails
ProblemNothing appeared wrong until the pager went off, and by then the customers had noticed first. Every post-mortem started with the same question: what were the metrics doing beforehand?
Anomaly detection and incident prediction running on Prometheus exporters and the metric collection already in place, so unusual behaviour is surfaced while it is still cheap to act on rather than after the pager goes off.
ValueThe incident is caught while it is still a queue depth and a latency curve, not after it is an outage and an apology. Nothing new had to be installed on the hosts to get there.
A support desk with agents behind it
ProblemThe same handful of questions arrived all day, and the few people who could answer them were too busy answering them to fix the thing causing them.
A multi-agent IT support system. One agent triages, another retrieves from the documentation an estate actually has, a third prepares the change, and a person approves anything that touches a live system. Every step is recorded.
ValueTicket volume stops scaling headcount for headcount, because the reading, looking up and drafting happen without a person. The person stays where the judgement is, and every action still has a name against it.
An assistant that knows the estate
ProblemThe answer was written down somewhere in the documentation. Getting it meant asking a colleague, and the colleague who knew was usually the one on holiday.
An IT support assistant answering from an organisation's own documentation, citing the page it used, and admitting plainly when the answer is not in there.
ValueThe answer arrives in seconds with the page it came from attached, rather than from whichever colleague has been doing the job longest.
A control plane for model usage
ProblemDifferent teams were using different models, the invoice landed once a month, and nobody could say what had run, on whose authority, or what it had been allowed to touch.
Model routing, prompt and version management, spend ceilings and tracing in one place, so a business can answer what ran, on whose authority, and what it cost.
ValueModel spend and model risk stop arriving as a monthly surprise. Cheaper models take the easy traffic under the same accuracy bar, and an auditor gets an answer rather than a shrug.
A booking site that answers first
ProblemThe phone rang while the owner was mid-appointment, and half the questions on the other end were ones the website should have been able to answer by itself.
A beauty business website with online booking and an assistant that handles service, price and availability questions, then hands the conversation to the owner the moment it should not be guessing.
ValueBookings arrive while the owner is with a client instead of waiting for a shop floor to empty, and the questions an assistant should not invent answers for still reach a phone.
A job portal that ranks on more than keywords
ProblemGood candidates were filtered out because their CV happened not to use the same words as the advert, and the shortlist looked the same every single round.
A recruitment portal with search, application handling and matching that weighs what a CV actually says rather than only the words that happen to overlap with the advert.
ValueShortlists form around what candidates can actually do, so the person who wrote the advert badly is not filtered out before anyone reads the application.
A consumer health app, built end to end
ProblemOne person's health data sat across several vendor accounts and a shelf of wearables, and every useful question about it had to be asked of somebody else's cloud first.
A self-hosted health and wellness platform: Go backend, web app and mobile clients running on the owner's own database, with food, sleep, exercise, symptom and medication logs syncing from the usual wearables and health APIs. Identity, consent and the data model were designed before the first screen, because those are ruinously expensive to retrofit.
ValueWhat explains the data is a multi-agent collaboration platform rather than one model working from a summary. Specialised agents for pattern analysis, product matching and nutrition refinement work over the same records through an MCP tool layer, each on its own model, so no single model is the product. Health data and model keys stay on the owner's infrastructure, and every model call is logged.
None of these were bought as an AI project. Each was bought as an answer to a specific, expensive annoyance that somebody had already stopped noticing. That is usually what arrives here, and it is why the first line above is the one worth reading.
What it turns on
The questions behind those builds.
Every project above came down to a handful of decisions like these. They are the level we work at, and the level we will happily argue with you about on the call.
Was the process ever worth automating?
Timed on the real steps, in about an afternoon, before anything is built. The number is agreed at the start and the project is judged against it at handover.
How do you test an assistant nobody has tested?
Build a set out of the hardest questions your team already answers, then make every change prove itself against those. The set is the deliverable, not the demo.
What does £1,000 of website actually buy?
Where the money goes on a fixed-price launch site, and the three decisions that quietly make a cheap site expensive two years later.
Where does our data actually go?
UK GDPR and residency for hosted models, which vendor terms retain and train on, and the questions worth putting to their security team in writing.
Will it say when it does not know?
Refusal matters more than accuracy on the easy questions. An assistant that cites its source and declines otherwise is the one you can put in front of a customer.
Next step
Find out in thirty minutes whether this is worth your money.
A call with the person who would do the work. If AI is not the answer for you, we will say that and point you at what is.