How an engagement actually runs.
We have no published case studies yet. So rather than ask you to take our word for it, here is the whole engagement written down: the first week day by day, what lands in your hands at each phase, how we bill, what you own at the end, and the work we turn down.
The whole job
A loose idea goes in. A system that holds comes out.
That transformation from tangle to beam is what the phases below are for. Nothing about it is magic; all of it is method.
Your first week building an AI system
Five working days with a fixed shape. By the end of them you have an architecture you can argue with, and one real slice of the system running on your own data.
Kickoff, access, constraints
- A working session with the people who own the problem and the people who own the data.
- Access set up: repositories, the systems in scope, and whoever has to approve them.
- A data-and-constraints audit: what data exists, where it lives, what is not allowed to leave your network, and what a wrong answer costs you.
A written constraints list: data residency, latency, approval points, and what the system must never touch.
Architecture proposal
- We pick the models and say why: hosted API, open-weight on your own infrastructure, or both in one system.
- Orchestration, retrieval, tool boundaries, human checkpoints, and the failure modes each one covers.
- The one slice we prove first, and how we will know whether it worked.
An architecture proposal: a diagram, the named components, the options we rejected and why, and a fixed-scope build plan.
A working spike
- We build one real slice end to end, on your data, inside your constraints.
- Demoed live on a call, not described in a deck. The code lands in your repository.
- If the spike shows the approach is wrong, we say so and change it. That is what the week is for.
Running code in your repository, a recorded demo, and an honest read on what it proved and what it did not.
A written constraints list, an architecture proposal with the rejected options still in it, and one working slice of the system running in your own repository, or a documented reason the approach was wrong, arrived at in a week rather than a quarter.
- A named technical contact who can answer questions the same day.
- Read access to the systems in scope, or someone who can run queries for us.
- An hour on day one from whoever owns the outcome.
From the first call to a system you run yourself
Week one is the front of phases one and two. This is the whole arc, and what you hold at the end of each part of it.
Discovery & scoping
Kickoff, access, and the data-and-constraints audit. We write down what the system must do, what it must never touch, and what a wrong answer costs. If you do not need an agent, this is where we say it.
- A written constraints and requirements list
- A scope and a fixed price for the build
- A recommendation, including "do not build this"
Architecture & proof of concept
The architecture proposal and the working spike. We prove the risky part first: retrieval quality, tool reliability, latency, whichever is most likely to sink the project. A failure here is cheap; the same failure in month three is not.
- An architecture document with a real deployment diagram
- The spike running in your repository
- An evaluation of what it proved and what stays uncertain
Build
We build in your repository, on your stack, in slices you can run as they land. A weekly demo of what works, not a status report. Evals and guardrails are written alongside each feature, not added at the end.
- Working slices in your repository each week
- Tests, evals, and the prompts under version control
- A staging deployment you can put in front of real users
Deploy & handover
Deployment to your cloud account, your VPC, or your own servers, air-gapped if that is the constraint. Monitoring and cost tracking wired up before go-live, then we walk your engineers through the system until they can change it without us.
- A production deployment on your infrastructure
- A runbook, architecture docs, and the evaluation set
- A handover session with your engineers, recorded
Ongoing support
Some teams take it from here; the handover is built for that. Others keep us on retainer for upgrades, new capabilities, and someone to call when a model changes underneath a prompt.
- An agreed block of engineering time each month
- A named route to reach us when something breaks
- The right to stop at any point and keep everything
Three ways to work with us
Every one of them starts with the same discovery, because none of them are worth quoting before we have seen your constraints.
Fixed-scope project
Scope and price agreed after discovery, before the build starts. If the scope changes, we re-quote in the open rather than quietly cutting corners.
A first agentic system, a private model deployment, or the application around one.
Retainer
An agreed block of engineering time each month. You direct where it goes. Cancel any time and keep everything built to that point.
A live system that keeps growing, or an in-house team that needs extra capacity.
Advisory
Architecture reviews, build-versus-buy decisions and audits, no build attached. A written opinion you can act on with us or without us.
You have engineers and need a second opinion before committing to an approach.
Not sure which one fits? Describe what you are building and we will tell you which we would propose, including none of them, if that is the answer.
What you own: all of it
All of it. This is a studio, not a platform, and there is nothing in the engagement designed to make leaving expensive.
Written in your repository, under your organisation, from the first commit. No wrapper SDK that only runs while you are paying us.
Deployed into your cloud account or onto your own servers. We work inside your accounts, not ours, so nothing has to be migrated at the end.
Open-weight models running on your hardware stay on your hardware. We do not train on your data, and we do not keep a copy of it after handover.
Architecture docs, a runbook, and the evaluation set. All of it written so your engineers can pick the system up, not so that they have to call us.
If you stop working with us, nothing stops running. That is the test we design against, and it is the reason we build on your stack rather than ours.
Where we say no
The quickest way to lose a client is to sell them an agent they did not need. These are the calls we make out loud, usually on the first one.
If your workflow always follows the same steps, it needs a script (or a cron job and a queue), not an agent. We will tell you that, even when the agent is the larger invoice.
Retrieval cannot rescue data you do not have. RAG over a folder of scanned documents nobody has ever read is a data project first and an AI project second.
A hosted API is often the honest answer. Running your own models is worth it when data cannot leave your network, when a regulator says so, or when your inference bill has outgrown a server. Not by default.
If every output has to be provably correct with no human in the loop, current language models cannot give you that. We will design the checkpoint and say where the risk sits instead of pretending otherwise.
We are a small studio. If your timeline needs more engineers than we can put on it properly, the honest answer is that it is not us, and we would rather say so on the first call.
When the answer is no, you still get the answer we would have charged for: what we think you should do instead, in writing, whether or not it involves us.
Tell us what you're building.
A short description is enough to start. If the first week is not the right next step for you, we will say that too.