How we build
Twenty years, three ways of working, one bench of engineers.
Here's what that actually looks like — including the parts most agencies leave out.
Three ways in
Embedded teams
When it fits. You have a product and a process. What you need is senior capacity you can't hire fast enough.
Who leads. You do. We adopt your process, your tooling, your ceremonies — whatever you actually run rather than what's on the wiki.
How it scales. One engineer or eight, up and down with your roadmap.
How it ends. Notice period, handover, documentation. No lock-in. If we're still here after eight years, it's because you wanted us to be.
Build from zero
When it fits. A new product, a spinoff, an MVP — and nobody in-house has taken one from nothing to production before.
Who leads. Our project manager and architect, with your product owner. You stay in every decision that matters.
How it scales. Small during discovery, wide during build, thin at handover.
How it ends. You own the code, the documentation and the pipeline. We stay for maintenance if you want us, and leave cleanly if you don't.
Takeover & rescue
When it fits. Someone else started it and stopped. Or it's live, it's critical, and nobody left in the building understands it.
Who leads. We do — starting with an audit, before anyone promises a date.
The first move. A two-week assessment: what's salvageable, what isn't, what each option costs. Sometimes the honest answer is “rewrite it,” and we'll say so before you've paid us to patch it.
How it ends. Working software, documented, yours.
Two ways we bring AI in
Most of what's written about AI in software assumes you're starting fresh. Almost nobody is.
From day one
When we build from zero, the process is designed around the tools from the start.
Specifications and user stories are written through a guided process with defined phases and approval gates. Clickable prototypes are generated from those specifications — so the spec and the thing you click are one artifact, instead of two documents drifting apart over six months. Testing runs continuously: an agent walks the application the way a manual tester would, and reports what works and what doesn't. Code and consistency review run through agents built for that specific project, not off the shelf.
We're running this now on a multi-tenant inventory platform for hospitals and operating theatres. Against our own pre-AI baseline on comparable work: specifications and feature delivery are landing around five times faster, and a full test pass across the application takes about a tenth of the time.
Into a team that's already running
This is the harder one. It's also the one most of our clients actually need.
You have a team, a process, and a decade of decisions nobody wrote down. You can't stop and restart, and any consultant who suggests you should has never had to.
So we don't. We put one system at the centre of the process — one that learns your domain, your entities, your integrations — and then we let it be wrong in front of everyone.
Because this is the part that matters: when it gives a poor answer, we don't correct the answer. We ask what led it there.
Which source did it read? Which source didn't exist? Nearly every time, what we find isn't a flaw in the model. It's something your organisation never wrote down, wrote down twice, or wrote down wrong.
Fix that, and the answer corrects itself — along with every other answer that would have depended on it. You stop patching outputs and start repairing the ground they stand on.
Over months, two things happen at once. The system gets steadily better at your domain. And you end up holding the documentation, the definitions and the decision history you always meant to write — produced as a by-product of ordinary work, instead of as a project nobody wants to fund.
It's slow on purpose. The constraint was never the model. It's the habit of asking “why did you say that?” — and habits take a while.
Where the tools earn their place
Specifications that stay true. Written through a guided process, with prototypes generated from them and checked against each other automatically, so they can't quietly diverge.
Testing at a different scale. An agent walks the whole application the way a person would. A full pass now costs roughly a tenth of what it used to — which means it happens far more often.
Reading unfamiliar code. The hardest part of inheriting someone else's system has always been understanding it. That's the part that changed most, and it's why our takeover work moves faster than it did two years ago.
Test coverage on legacy systems. Writing tests for code you didn't write used to be the least popular job in software. It's now tractable — so we can refactor systems we'd previously have advised you to leave alone.
Migrations and framework upgrades. Mechanical, repetitive, and historically where budgets went to die.
Where we don't let them near
No automatic commits. The tool proposes. A person approves. Always.
Plan first, then build. Nothing changes until someone has confirmed what is about to change.
Never near real patient or production data.
Your source systems stay read-only. We read them to understand them. Nothing writes back.
Architecture, security boundaries, and domain logic where wrong is expensive stay with people who have been wrong before and remember how it felt.
What nobody tells you
We've been at this long enough to have collected the failure modes.
Confident and wrong is a new failure mode
Our most persistent problem on the hospital platform was never code that broke. It was specifications and code that read perfectly, followed every convention, and quietly disagreed with the actual database. A junior's mistakes look like mistakes. This doesn't.
What we do about it: nothing enters the work without being grounded in the live schema, and an automated check confirms the specification and the prototype still say the same thing. Both of those exist because we got burned, not because we planned them.
The bottleneck moved
It used to be writing code. Now it's reading it. Speed up generation without adding review capacity and you haven't built a faster team — you've built a faster way to accumulate technical debt.
Estimation got harder, not easier
The first eighty per cent is dramatically faster. The last twenty per cent is not. Every estimate built on the old ratio is now wrong in a new way.
Juniors stop becoming seniors
If the tool answers before anyone has sat with the problem, the thing that produces a senior engineer never happens. We think about this more than we expected to.
None of this is an argument against the tools. It's an argument about who's holding them.
What review is for now
Automated checks run before a human looks at anything.
Consistency between specification and prototype, and a full automated test pass. What that changed isn't how much we review — it's what review is for. Our seniors stopped catching typos and started spending that attention on decisions and business logic, which is what we were paying them for in the first place.
Every change still gets a senior review. That's why half our team is senior. It isn't a hiring boast — it's a review constraint.
Talk to someone who'll actually be on the project.
Four founders, all still hands-on. Whoever scopes your project is the one who'll be in it.