How we work
Most of what determines whether a software project succeeds is decided before anyone writes code, and most of it is dull. Here is how we run an engagement and how we build AI features that survive contact with real users.
Days, not weeks
We work out what you actually need built, which is often not what the brief says. You get a written scope with a price attached before any code exists.
Runs alongside build
Interface and architecture get decided together, because for AI products they constrain each other. A model that takes four seconds to respond is an interface problem as much as an engineering one.
Short cycles
You see working software early and often. Nothing is built for months behind a curtain, which means you can change your mind based on something real rather than a document.
Boring by design
Deployment is automated and rehearsed before launch day. You get the repository, the infrastructure config and the documentation to run it without us.
Optional, ongoing
Monitoring, model updates and evaluation runs. AI features drift as providers deprecate versions and real usage diverges from what you tested — this is the part most studios leave you to discover alone.
The AI part
We write the evaluation set — real inputs with known-good outputs — before building the thing it measures. It runs on every change, like a test suite. Without it, nobody can tell you whether a prompt tweak broke an edge case.
Providers deprecate versions, change pricing and adjust behaviour without asking. We put a boundary around model calls so swapping one out is a contained change rather than a rewrite.
Most problems described as needing a custom model need the right context supplied at the right moment. Retrieval is cheaper, updates instantly when your data changes, and lets you show a user where an answer came from.
Models produce confident nonsense on a schedule nobody controls. The interesting engineering is in what happens next — confidence thresholds, human handoff, showing sources, and making the failure legible rather than silent.
We scope and price per project rather than billing hourly, so you know the cost before we start. For longer engagements we work in fixed-price phases — each phase has its own scope and price, and you decide whether to continue at the end of each one. Retainers are available for ongoing work after launch.
You do. On final payment, all source code, designs and associated IP transfer to you outright. We keep no licence over your product and we do not reuse your code in other clients’ projects. You get the repository, the infrastructure config and the documentation to run it without us.
No. We do not train models on your data, and we do not send your data to providers who do. Where a project uses a third-party model API, we use configurations that exclude your inputs from training, and we tell you in writing which providers process what. If your data cannot leave your infrastructure at all, we design for self-hosted models instead.
We build an evaluation set before we build the feature — real examples with known-good outputs — and we run it on every change, the same way we run a test suite. That is how we catch a prompt change that quietly breaks an edge case, and how we can tell you a model swap is safe. If a problem cannot be evaluated, that is usually a sign it should not be solved with a model.
We will tell you. A good deal of what gets pitched as an AI problem is better served by a database query, a rules engine or better-designed software, all of which are cheaper to run and easier to reason about. We would rather build you the boring thing that works than the impressive thing that does not.
It depends on scope, but we work in short cycles and put working software in front of you early rather than disappearing for months. You will see something running well before it is finished, and you can change direction based on what you see instead of what you imagined at the start.
Yes. A good share of our work is adding capability to systems that already exist rather than starting over. We can work alongside your engineers, hand over progressively as they get comfortable, or run the whole thing — whichever fits how your team is set up.
Software that nobody watches degrades, and AI features degrade in ways ordinary software does not — model providers deprecate versions, and real usage drifts away from what you tested. We offer ongoing support covering monitoring, model updates and evaluation runs. If you would rather run it yourselves, we hand over the tooling and documentation to do that.
Ask it before you commit to anything. We would rather talk you out of a project early than take one on that was never going to work.
Start a conversation