How we work · one project, end to end
Prove it.
Harden it.
Own it.
Every project takes the same path: proven fast, hardened by an automated pipeline, then owned for its life. The sequence does not change, which is the point. Scroll to walk it once.
Station 01 · The material
The admin is the material.
The forms, the approvals, the reconciliations, the eleven-day handoffs, the spreadsheet somebody rebuilds every month. Across roughly fifteen countries, that work is done by people who were hired to do something else.
It is unglamorous, it is enormous, and it is almost entirely automatable. That is the material we work in.
Station 02 · Part 1 — PoC Services
Prove it, fast.
Business-fluent engineers embed in a business, work out how it actually runs, and build something working with AI agents. They prove — or disprove — the value, take it to MVP, and hand it over.
- Profile
- Forward Deployed Engineers
- Clock
- Days for something simple, weeks for something complex
- Ends when
- Value is proven and the handover pack is delivered
Station 03 · The industrialisation pipeline
Every project passes through it.
With no exceptions.
An agent plans, then an automated workflow adds what a prototype does not have: multi-user scale, authentication, async execution, APIs, webhooks and tests. Humans are involved only when the agent asks for them.
A near-MVP with the value proven
A deployed, tested, secured, multi-user system
Station 04 · Part 2 — The Tech Lab
Then somebody owns it.
A Product Owner and a developer take the hardened product and own it for its life: gathering needs from the business, continuing to build, maintaining, and running it.
- Profile
- Product Owner · developers · DevOps
- Clock
- Continuous, for the life of the product
- Ends when
- Never — this is the team that keeps it alive
Station 05 · The loop closes
What running it teaches
becomes the next intake.
You have gone round once. That is the whole company: a repeatable, agentic path from idea to running product, and back again.
The whole track, in detail →A PoC function with no product team is a prototype graveyard — impressive demos, nothing in production. A product team with no PoC function builds things nobody asked for.
Most automation programmes have exactly one of the two, and blame the people rather than the structure. This one is built as a loop so it cannot happen.
Why we build faster
Every implementation starts with an agent that plans it, works the architecture through, and reviews what comes out. Engineers direct that work and decide what ships. The gain is not that more code gets written — it is that the slow parts of building, the reading and the checking and the honest second opinion, stop being the thing everything else waits on.
Review is done by something that did not write the code and has no memory of intending anything by it. An author checking their own work, human or not, reliably confirms what they meant to do rather than what they actually did.
Agents also do not go home. A fault at three in the morning is picked up when it happens, traced back to what actually broke, and answered with a proposed fix waiting when the team arrives. Nobody is woken up, and nothing sits untouched until Monday.
People are better at judgement, at context, at knowing whether a thing is worth building at all. They are not better at being continuously available, and asking them to be is how teams get worn out. So we use people for the first and agents for the second.
Nothing an agent produces reaches production without a person approving it. That constraint is what makes the rest of this safe to say.
The whole track
The walkthrough above is one revolution of this. Here it is step by step, which is what you want if you are deciding whether to hand us something.
Part 1 · PoC Services — prove it
- 0 Intake
The problem, the owner, the success criterion, what it costs today and what data it touches — then scored into a size tier by someone who does not own the outcome. That independence is what makes the promise honest.
- 1 Understand the process
How the work actually runs today, observed rather than described. Most of the value is found here, not in the build.
- 2 Check what already exists
Reuse before reinvent, applied before a line is written.
- 3 Write the functional architecture
Spec-rigour before build. What it does, for whom, and what done means.
- 4 Agentic build
Agents do most of the building. The engineer directs, reviews and decides.
- 5 The stakeholder loop
Three increasingly real prototypes, shown to the people who do the work while it is still cheap to be wrong. Each showing opens by saying what it is not yet.
- 6 Near-MVP and the handover pack
Value proven or disproven, plus everything the next team needs. Near-MVP means usable, not production — the pipeline sits between.
The industrialisation pipeline — harden it
- I Drop in
Nothing skips it. It refuses to start without a codebase that builds from a clean clone, its labels filled in, and a named person who can answer for it.
- II It is planned
What industrialising this thing means is written down before anything changes. That plan is what everything else works from, and what a person reads when a decision is needed.
- III It is hardened
A prototype becomes production software. This is the step that changes the security and infrastructure answers, and it is the same step for every project.
- IV Humans, only when asked for
The engineer who built it, with the Head of Engineering — not a standing review board. Their second job: making sure the builder understands what was built. A handover written by someone who does not is not a handover.
- V Tests, security, deploy
A 100%-pass gate. The machine decides done; a human decides go.
Part 2 · Tech Lab — keep it alive
- 7 Handover to a pair
A Product Owner and a developer take on something they did not build — which only works because every product arrives shaped the same way. They accept it by testing it.
- 8 Own it, build it, run it
Continuous. The PO holds the business relationship, the backlog and acceptance; the developer holds the build, the architecture and the release. A product that stops evolving stops being used.
- 9 Graduation, if it ever leaves
Some products stabilise and stop needing build velocity. Leaving is a named path, agreed case by case, never drift. A success condition, not a failure.
Two rules that set the pace
- The clock is the process, not the calendar
- Days for something simple, a quarter for something genuinely hard — set by the complexity score at intake. A short timebox on an unexamined process does not make the work faster; it makes the first honest conversation happen later. And an honest no is a delivered outcome: if the value is not there we stop and write it up.
- Every showing opens by saying what it is not
- What it does, and what it explicitly does not do on security, infrastructure and data — stated before the demo, not after. Ten minutes into working software a caveat sounds like backtracking; said first it sounds like scope. This matters most at near-MVP, which looks far more finished than it is safe.
What a handover actually contains
The handover pack is not a pack. It is the repository, plus the things a repository cannot hold. Most of it is written during the stage that produces it, not assembled at the end.
- The repository
- Not a folder of documents — the repo itself: front door, doc index and reading order, the architecture, and a decision log recording what was chosen, why, and the trigger to revisit it.
- Four product documents
- The process map as the work is actually done. The functional architecture. The benefit case with its measured baseline. The stakeholder map: who cares about what, and who to call when it breaks.
- The technical-depth statement
- What was reviewed and by whom — or plainly, that nothing was. Where the design was left shallow, and the gaps the builder already knows about.
- The runbook
- Deploy and rollback, performed rather than described. Every alert and what it means. The three things most likely to break. The record of the restore drill.
- The roadmap
- What was deliberately not built, and why.
- Onboarding flows
- A first-run path in the product, a one-page how-to for the commonest task, and the named first cohort actually onboarded before handover.
- Six registry fields
- Owners that resolve to real people. Binding size tier, data classification, risk tier, declared deviations — and a decommission condition, never blank.
- Two bounded meetings
- A recorded ninety-minute walkthrough and an introduction to the stakeholders. Then it ends.
The pack is accepted by testing it
A cold start: the receiving developer, alone, from a clone, with nobody to ask, gets it running and ships one trivial change. Until that passes the builder is not out. Afterwards they answer pack defects and never product questions — a question only the builder can answer is the defect. Then they leave completely.
Staffing follows a score, not a judgement
Size is a composite score across three axes — surface (how far the blast radius reaches), run load (what it costs to own) and build complexity — not a negotiation. Complexity is deliberately the lightest-weighted: where agents do most of the building, build effort is the cheap input and ownership is the scarce one.
The tier set at intake is a forecast. It is re-scored at handover by people who have built the thing and watched real users touch it, and that is the one that binds. A pair inherits a tier, not an opinion.
Something in your business
that shouldn't be manual?
Tell us how the work actually runs today. If there is something there, you will know in days rather than quarters.