Model 01
Fixed-Scope Project
When the problem is well understood, the boundaries are clear, and a defined version one outcome is agreed.
You receive
Complete end-to-end working system delivered against agreed acceptance criteria.
PROCESS
Six stages, no surprises.
Most projects fail in the gap between what was agreed and what was assumed. This is how we close it.
THE DELIVERY ENGINE
Disciplined execution from concept to handover.
Every stage has a documented output and a checkable quality gate before the next begins.
01
Discover
We talk to the people who will use the system and the people who will operate it, map the constraints that are genuinely fixed, and establish what would make the project a failure. Most of the value here is in removing scope, not adding it.
Stage 01 deliverable
Output:
A written problem statement, with what is out of scope named explicitly.
Objective:
Understand the problem before proposing a shape for it.
02
Define
Scope, success criteria that can be checked rather than admired, and a sequence. We would rather argue about this document now than about an invoice later, so it is written to be disagreed with.
Stage 02 deliverable
Output:
A scoped specification and a delivery sequence you have signed off.
Objective:
Agree what version one is, and what it deliberately is not.
03
Architect
Data model, service boundaries, integration contracts, and the hosting position. Every significant choice gets a decision record stating what was chosen, why, and what was given up — so a future team can revisit it deliberately rather than by accident.
Stage 03 deliverable
Output:
Architecture decision records, a data model, and a cost estimate for running it.
Objective:
Choose the shape of the system, and write down why.
04
Build
Work in cycles with something demonstrable at the end of each. Tests written alongside the code. Preview environments per change. Written progress notes, including what went wrong — a status report with no bad news in it is not a status report.
Stage 04 deliverable
Output:
Working software in a real environment, updated every cycle.
Objective:
Ship a thin working path first, then thicken it.
05
Validate
Error handling, observability, access control, load behaviour, and a restore tested from an actual backup rather than assumed. This is the stage most projects compress, and where most incidents are subsequently traced back to.
Stage 05 deliverable
Output:
Test results, a tested restore, and monitoring wired to a real destination.
Objective:
Prove it survives production, not just a demo.
06
Evolve
Runbooks, architecture notes, and enough pairing that your team can operate and extend the system without us. Then a continuing cadence for whatever the product turns out to need, at whatever level of involvement suits you.
Stage 06 deliverable
Output:
Documentation, recorded handover sessions, and an agreed support rhythm.
Objective:
Hand over properly, then keep improving it.
CLIENT INVOLVEMENT
What we need from your team.
Projects fail when expectations around client participation are vague. Here is what we ask of you at each stage.
| Stage | What We Need | Who Needs to Be in the Room |
|---|---|---|
01 · Discover | Context on the problem, access to users, and honest discussion of prior attempts. | Problem owner & operational stakeholders |
02 · Define | Clear sign-off on what 'done' means, scope boundaries, and agreed constraints. | Decision maker + domain expert |
03 · Architect | Clarity on hosting preferences, third-party contracts, and data access policies. | Technical stakeholder (if applicable) |
04 · Build | Attendance at weekly demonstration cycles and rapid feedback on working slices. | Product owner / designated champion |
05 · Validate | Realistic testing with real operators against acceptance criteria. | End-users and operational team |
06 · Evolve | Dedicated handover pairing and establishing ongoing maintenance cadence. | Internal engineering or operations leads |
ENGINEERING HYGIENE
How we work day to day.
The practical engineering habits that make complex systems predictable to ship and maintain.
Standard 01
Weekly Running Demos
Every cycle ends with software running in an actual environment. We review working code, not slides or progress spreadsheets.
Standard 02
Written Decision Records
Every meaningful architectural choice is documented as an ADR: what was decided, why, and what was intentionally given up.
Standard 03
Direct Engineer Access
You communicate directly with the software engineers building your system, eliminating translation delays and miscommunication.
Standard 04
Continuous Integration & Preview Environments
Every pull request builds isolated, production-like preview environments with strict automated testing before merging.
Standard 05
AI-Accelerated Tooling, Human Verified
We build with current AI tooling (Cursor, Claude Code) for rapid generation, with strict human architectural review as the gate.
Standard 06
Zero-Downtime Migration Thinking
From day one, systems are structured so schema migrations, cloud cutovers, and rollbacks happen without taking users offline.
ENGAGEMENT MODELS
Engagement shapes suited to your context.
We structure engagements around the clarity of the problem and the level of internal team involvement.
Model 02
Discovery Engagement
When the problem is clear but the technical approach, legacy constraints, or architecture options require deep investigation before scoping.
You receiveTechnical specification, architecture decision records, data model, and de-risked delivery roadmap.
Model 03
Ongoing Partnership
When you require dedicated senior engineering capacity for continuous platform evolution, scaling, and architectural stewardship.
You receiveOngoing iterative feature delivery, reliability monitoring, and direct technical leadership.
Have something ambitious to build?
Tell us what you're working on. We'll tell you honestly whether we're the right team for it.