Five phases, and three ways to contract for them.
Big platforms fail on skipped thinking, not bad code. This engagement makes the thinking a deliverable — and gives you a defensible exit at the end of every phase, not just the end of the programme.
What moves the priceUnderstand
Discovery workshops with the people who live the problem, not only the ones who commissioned the project. Process walk-throughs, data audits, stakeholder interviews, and shadowing where it matters. This phase is paid and self-contained — the artefacts are yours whether or not we build.
What you receive
- Problem definition document
- Current-state process maps
- Stakeholder and constraint register
- Opportunity sizing
Who we bring
A principal architect and a business analyst, on site for part of it.
What we need from you
Two to four hours a week from the people who do the work, plus a sponsor for the decisions. Not a committee.
Before the next phase starts
- Process maps signed off by the people whose process they describe
- A written problem definition both sides recognise
- Enough understanding to size the work honestly — or to say it should not be built
Define
The solution blueprint — target architecture, module scope, integration contracts, phase plan, and the success metrics we will be measured against. This document is the deal; everything after it is execution.
What you receive
- Target architecture
- Phased delivery roadmap
- Success metrics and SLAs
- Commercial structure
Who we bring
The architect who ran discovery, plus a designer and a delivery lead.
What we need from you
A decision-maker who can approve scope and a technical contact who can answer integration questions.
Before the next phase starts
- Target architecture and integration contracts agreed
- Phase plan with the metrics we accept being judged on
- A blueprint another firm could tender against — the natural stopping point if you want to
Build
Fortnightly releases into a live environment with your credentials. Scope is versioned, so a change is a decision with a visible cost rather than an argument at the end. Nothing disappears into a black box for a quarter.
What you receive
- Fortnightly releases
- Live environments
- Versioned scope
- Running test suite
Who we bring
The delivery lead, the engineering team, and the architect throughout.
What we need from you
A product owner for a couple of hours a week, and reviewers available inside the sprint.
Before the next phase starts
- Working software in your environment every fortnight
- Agreed acceptance criteria met per release, not at the end
- Documentation current as of the last release, not written afterwards
Prove
Security review, penetration testing, load and failover drills, and user acceptance with the people who will actually operate the system. Go-live is a scheduled event with a rollback plan, not a hope.
What you receive
- Security review
- Load and failover report
- UAT sign-off
- Runbooks
Who we bring
Two to three engineers and the architect.
What we need from you
Access to a non-production environment and someone to review what comes out of it.
Before the next phase starts
- The riskiest assumption tested against real data or real load
- A go / no-go with the reasoning written down
- A revised estimate if the spike changed what we know
Operate
SLA-backed operations by the team that built it, quarterly architecture reviews, and a roadmap that fits your budget cycle. If you want the platform in-house later, handover is a phase we run rather than an argument we have.
What you receive
- 24×7 SLA operations
- Quarterly architecture review
- Roadmap cycles
- Handover on request
Who we bring
An SRE pod with named primary and secondary on-call, and the same architect.
What we need from you
A named contact for severity decisions and a quarterly review slot.
Before the next phase starts
- SLA agreed with defined severities and response times
- Monthly reporting on uptime, incidents and spend
- A transition plan available at any point, run at standard rates
The same five phases. Three ways to structure them.
What changes between these is who carries scope risk, how a change in direction is handled, and how you leave. The engineering standard and the senior team do not change.
Fixed-scope delivery
A defined blueprint, a defined price, defined dates. The right shape when the Define phase is complete and the destination is agreed.
Usually chosen when
- · This is the first platform we build for you
- · The budget is board-approved against a figure
- · Procurement requires a fixed baseline
Specific to this shape
- The solution blueprint is the contract baseline
- Priced phase by phase against delivered outcomes
- You can stop at the end of any phase and keep its artefacts
Dedicated team
A named squad — engineers, design, delivery lead — working to your priorities month by month, inside your repository and your board.
Usually chosen when
- · The roadmap will change faster than a blueprint can
- · The programme runs for years rather than months
- · You are building an internal technology function alongside it
Specific to this shape
- You set the priorities each sprint; direction changes cost nothing
- Monthly commercial cycle, quarterly review of team composition
- Thirty days' notice, with no exit fee
Build–operate–transfer
We build the platform, run it in production until it is boring, then hand over a working system with a trained team and current documentation.
Usually chosen when
- · The capability is meant to end up in-house
- · A new venture that will eventually staff its own engineering
- · Institutional and public-sector programmes with a transfer mandate
Specific to this shape
- An operate period under SLA with a named on-call rota
- Hiring support and training for the team that takes it over
- A parallel run before transfer, and a support runway after it
The same three shapes, on the axes you are weighing.
| Fixed-scope delivery | Dedicated team | Build–operate–transfer | |
|---|---|---|---|
| Best when | The destination is agreed and a blueprint exists. | The roadmap will evolve and priorities shift quarterly. | You want the capability to end up in-house. |
| Who carries scope risk | We do, within the agreed baseline. | You do — you set priorities each sprint. | We do during build, you do after transfer. |
| How it is priced | Phase-wise against delivered outcomes. | Monthly by team composition. | Monthly during operate, fixed fee at transfer. |
| Minimum commitment | A phase. | Three months. | Eighteen months of operate. |
| Changing direction | A priced change request before work starts. | Next sprint, at no commercial cost. | Next sprint during build; transfer terms are fixed. |
| How you leave | At the end of any phase, with that phase's artefacts. | Thirty days' notice. | On the transfer date, or earlier by agreement. |
Which shape fits depends on how settled the scope is and who carries the risk if it moves — a twenty-minute conversation rather than a form. What the engagement costs is a separate question, answered by scope: the six drivers that move an estimate are set out in order.
How it is governed while it is happening.
The parts of a programme that decide whether it stays on track, and that most proposals leave to be improvised in month two.
Reporting cadence
A written status every fortnight against the phase plan — what shipped, what slipped and why, and what changed in the estimate. Monthly steering with the sponsor where the programme warrants one.
Your tooling, not ours
We work in your repository, your board and your CI wherever possible, so progress is visible without asking for a status update.
Access and security
Least-privilege access requested per environment and revoked at phase end. Where your policy needs it, we work inside your network on your devices.
Change requests
Scope changes are priced and agreed in writing before work starts, with the schedule impact stated. No change is absorbed silently — that is how a fixed date quietly becomes untrue.
Escalation
Delivery lead, then the architect, then the founder. Three steps with names attached, and the last one answers within a working day.
Decision log
Significant architectural decisions recorded with the alternatives considered. It is what lets a decision be revisited in year three without re-litigating it from memory.
What the code produced under that governance has to satisfy — review, testing, observability, the definition of done — is set out under engineering standards.
The phase most proposals stop before.
A platform is not finished when it launches; that is when it starts being load-bearing. What happens next is agreed before launch, not negotiated after it.
Hypercare
The build team stays on for the first weeks at build intensity, because the fortnight after launch is when the things nobody modelled show up.
Operations under SLA
Defined severities, response times and an on-call rota held by people who know the system — usually the ones who built it.
A roadmap, not a ticket queue
Quarterly planning against what the platform should do next, informed by what the telemetry says is actually being used.
Transition whenever you want it
Taking it in-house is a phase we run at standard rates, with the handover pack already current because it was a deliverable at every release.
How the contract is shaped.
The clauses that decide what happens when something changes — which is the part of a commercial arrangement that gets tested.
Payment against milestones
Tied to delivered outcomes rather than elapsed calendar time, so an invoice always corresponds to something you can look at. Discovery is invoiced separately from build, because it is separable.
Change requests, priced before work
Scope changes are estimated, agreed in writing with the schedule impact stated, and only then started. Nothing is absorbed quietly — that is how a committed date silently becomes untrue.
Switching shapes mid-engagement
Common and expected. Most programmes start fixed-scope for the first platform and move to a dedicated team once the roadmap outruns the blueprint. It is a contract amendment, not a renegotiation.
Transition and exit
Exit assistance at standard rates, with no penalty clause. The handover pack is current because it was a deliverable at every release rather than a promise for the end.
IP and source
Yours from the first commit, in your repository, with no runtime licence back to us. Source escrow available where your risk function asks for it.
Liability and insurance
Professional indemnity in place, with the cap negotiated against engagement value rather than fixed by us. The certificate is supplied at contract stage.
Asked in most first meetings
We do not publish prices, because scope drives them and a figure without scope is a guess one of us later has to defend. What we will tell you is what moves the number: integration surface, process variance, data condition, regulatory obligation, non-functional targets, and your own availability.
Phase one
This starts with discovery, not a proposal.
Two to six weeks, ending in four artefacts you keep: a problem definition, current-state process maps, a constraint register and a sizing. They are yours whether or not the build follows.
- No sales deck
- An engineer on the call, not an account manager
- NDA before you share anything