Methodology
Five phases that de-risk a large build.
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.
- Phases, each with an exit
- 5Phases, each with an exit
- Between working releases
- 2 wksBetween working releases
- Every artefact we produce
- YoursEvery artefact we produce
Understand
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
Running the engagement
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.
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.
The exit clause
Every phase ends somewhere you could stop.
Discovery produces documents you can hand to any vendor. Each build phase ends with working software in your environment.
Next step
Bring us the problem. We will bring the architecture.
A discovery call takes forty-five minutes. You leave with our read on the problem, the shape of the system we would propose, and a straight answer on whether we are the right team for it.
- No sales deck
- An engineer on the call, not an account manager
- NDA before you share anything