One yes, ten jobs
Deciding to build something is the small decision. What follows is the part that fills a year.
What a build really costs a team
Say yes to a customer portal, an internal tool or an assistant that answers questions about your own documents, and you have taken on the work behind it. Somebody has to choose the stack and defend the choice in two years. Somebody has to decide what the system is allowed to touch, and prove it to a client's security questionnaire. Somebody has to keep it up on the Monday the warehouse is behind, watch the bill, answer to a model provider that just retired the version you depend on, and make sure people outside the company can find the thing at all.
Few companies are short of ideas. They are short of the layer underneath: the engineers, the tooling, and the habit of running software that other people's work depends on.
- Hiring for skills that keep moving
- The engineer who can build a retrieval system, run a release pipeline and read an evaluation set is the engineer every company is trying to hire this year. Job ads for one person who does all three are how projects get stuck before they start.
- Security that has to hold up to somebody else's audit
- Access control, secrets, dependencies, audit trails. It is quiet work until a customer sends a security questionnaire, and then it is the only work.
- Being found, by people and by assistants
- Search still sends the visitors. Increasingly an assistant reads a page and answers on your behalf, and a site it cannot parse is a site it does not quote.
- Keeping it alive after launch
- Someone watches the logs, patches what needs patching, and renews the certificate before it expires. This is the part that gets dropped first and noticed last.
- Knowing when the answer is no
- The most expensive systems are the ones nobody could talk the business out of. A team paid to build rarely argues for a form and a query instead.
Built by the team that runs it
A studio hands over a repository at the end. A managed provider runs something it did not build. We do both halves, and you pick where the line sits.
The same engineers who design the system write the pipeline that ships it, the tests that gate it and the runbook the next team reads. When something breaks at nine on a Tuesday, nobody is reading the code for the first time.
You decide what happens at handover. Take all of it, keys and accounts included, and run it yourself. Leave it with us on a monthly arrangement. Or split it, with your team owning the product and ours keeping the delivery and evaluation machinery running.
We build it, you run it
The default. Code, prompts, evaluation sets, infrastructure and accounts transfer to you on final payment, with documentation and a training session so your team can take it from there.
We build it and stay
A monthly arrangement for systems in production: evaluation runs on a schedule, prompts and configs move as models move, and a named response time when something is wrong.
You have a team, we fill the gap
Your engineers own the product and we cover the layer they do not have yet, whether that is retrieval, the release pipeline or the evaluation harness. We write it so your team can read it.
Ownership does not change in any of the three. The code, the prompts, the evaluation sets and the accounts are yours at final payment either way. This is about who operates the system, and it is a decision you can reverse. What each one costs
What we are for
- Vision
- Software that a business understands, owns and can prove is working, with AI in the few places it earns its keep.
- Mission
- We build the systems a company would otherwise need three teams to keep alive, prove each one against its own data before anyone depends on it, and hand over something the next engineer can read.
- Most of what gets called AI should be an if-statement
- We put a model in the path only where the work calls for judgement. If a rule does it, we say so.
- A demo is not evidence
- Anything works once on a question the vendor picked. A score against your own queries is the thing worth having.
- Nobody should marry a model provider
- The model sits behind an interface, so switching one out is a config change and an evaluation run.
- The work should be readable by whoever comes next
- Documentation, a runbook and a training session are part of the build, not a favour at the end.
- Small enough to say no
- We take a few clients at a time. It is the only way to be in the room, and the only way to turn down work that should not be built.
What you can open and check
There are no testimonials on this site yet. These are the things you can open and judge for yourself.
- Working software, not slidesFive demos you can break in your browser, each one the small version of a real engagement.Try the demos
- What our own testing keeps findingThe methods we use to measure what we build, and the conclusions we have drawn from our own projects.Read the findings
- This site is a sample of the standardAccessible to WCAG 2.2 AA, static on every route, with its own module graph published from the last build.See what it is built with
- The price and the process in writingWhat the first meeting costs, what discovery covers, and the payment terms, before you talk to anyone.Read the pricing
The numbers we publish are 20+ projects delivered and 5+ industries served, with a typical build running 6-8 weeks. Named case studies are not published yet, so we do not imply them.
Start with the problem
A paragraph about what is not working is more useful than a specification. We reply within two working days.
Start a projectOr find the week that sounds like yours in the problems we are brought in for