.svg "kloia.png"){kind=logo}
Software Development (Greenfield)
Build It Fast
Build It So Someone Else
Can Own It
AI native from the first commit. Specification before code, tests before merge, a gate on every change.
The Same Engine, Started From An Empty Repository
AI has made greenfield fast for everybody, which means speed is no longer the advantage. The problem now is what fast produces: prototype quality code in production, no recorded decisions, and a codebase only the person who generated it can explain.
On a legacy estate the existing system tells us what the software has to do. On a new product there is no existing system, so the specification takes that role. The domain model, the target design and the architecture decisions get written and validated first. Then agents build against them, test first, and a machine checks the result before a person signs the merge.
One detail matters more than it sounds: the acceptance test suite is kept out of the building agent's reach. It only exists in CI. So when the build goes green it means the specification's tests passed, not that the agent's code passed the agent's own tests. That distinction is the difference between a real gate and theatre.
Who It's For
Companies building a new product or platform capability that has to survive its first team. Startups past the prototype stage that now need something auditable. Enterprises spinning up a new digital line of business. Anyone who has watched an AI-built prototype become the production system by accident.
What Unmanaged Speed Ships
Prototype quality reaches production because nothing stopped it.
It demoed well, the deadline arrived, and it shipped. Now it is load-bearing.
Our Solution :
Gates from the first commit. Tests written from the specification before implementation, held outside the agent's workspace, wired to branch protection.
There is no specification, so there is nothing to check against.
The requirements live in Slack threads and someone's head, so correctness is a matter of opinion.
Our Solution :
The specification is the unit of work. Agents draft it, humans curate it, and every requirement carries a stable ID traceable from spec to story to pull request to test.
Nobody can explain why the system is built this way.
Six months later a decision looks wrong and nobody knows whether it was deliberate.
Our Solution :
Architecture decisions recorded as you go, owned by a named person, version-controlled next to the code.
Velocity collapses when the founding builder leaves.
The product was a one-person artefact and now it is nobody's.
Our Solution :
The reasoning lives in the repository. A new engineer picks up the knowledge core, not an oral tradition.
Specify, Gate, Build, Gate
01
Design Before Build
Domain model, target architecture and decisions authored and validated first. Short. Not a six-month architecture phase.
02
Acceptance Tests From The Specification
Written before any implementation exists and checked into a place the implementing agent cannot see.
03
Agents Build, Reviewers Argue
Transformation agents work in parallel. Then review agents whose only job is to find problems: code review, simplification, dead comments, test quality, silently swallowed failures, type design. A reviewer that approves everything is treated as broken and replaced. Then a senior engineer fixes the genuinely hard part.
04
Machine Gate, Then Human Gate
The specification's own suite runs in CI and either passes or does not. Then a named person accepts and merges. Agents never merge, in this line as in every other.
05
Repeat Per Capability
An MVP is one bounded capability with a thin specification. The loop scales down to fit it. What does not scale down is skipping the loop.
Outcomes, With Their Qualifiers Attached
Production-Grade Software at AI Speed
Not a prototype you promise to harden later..
A Codebase Any Engineer Can Pick Up
The reasoning is in the repository. Onboarding stops being a transfer of folklore.
Decisions On The Record, Owned By Name
Auditable from day one, which matters a lot in a regulated market and eventually everywhere else.
A Gate That Actually Means Something
Green means the specification's tests passed, because the agent never had access to them.
No Hiring Wave To Get Moving
Agents do the volume. Your engineers hold the specification, the architecture and the merge.
What We Have And Have Not Done
We have not yet delivered this line as a standalone client engagement, and we would rather tell you that than dress up a case study.
What we can show you: the machinery is the same machinery we ran end to end on a large regulated modernisation programme, and we are currently running this line on our own internal product build, where the development-system design has been through adversarial review and holds the same load-bearing decisions we would bring to your project. CI as the only real gate, knowledge kept in the repository, acceptance tests held out of the builder's reach, humans merge.
If you want a reference for the engine, we will walk you through the modernisation engagement in detail under NDA. If you want a reference for this exact line, we do not have one yet, and the first client to take it gets priced accordingly.
FAQ
Is this over-engineering for an MVP?
Fast to demo, yes. The problems on this page are what unmanaged speed ships. What the method costs is what makes the speed durable: decisions you can audit, a specification that outlives the first team, and a gate that actually blocks.
Is this over-engineering for an MVP?
No, because the loop sizes to the slice. An MVP is one bounded capability with a thin specification. The parts you would be tempted to skip are the cheap parts.
Who owns the code?
You do, in your repositories, from the first commit.
What if we already started and it is a mess?
Then you are closer to our modernisation line than this one, at a smaller scale. Same method, different starting point, and we would tell you that on the first call.
Do we need to use your tooling forever?
No. The pipeline is installed into your repositories using standard CI. If you part ways with us, the gates keep working.
Start It Properly.
A short engagement that produces the specification, the architecture decisions and the acceptance suite, then builds the first capability through the pipeline so you can see the shape of it.