Each cycle
Pick
The next slice is chosen for what it proves, not for what is easiest to demo.
Delivery model
The work is the record.
A project that cannot be described in documents is a project that cannot be handed over, audited or defended. These are the artefacts each stage produces, and who they are for.
At a glance
- Stage 01
- Scope & questions
- Stage 02
- Model & permission matrix
- Stage 03
- Reviewable increments
- Stage 04
- Release & rollback
- Stage 05
- Handover or support
01Discovery
Two pages that decide whether the project is worth doing.
Discovery is bounded and paid. It ends in a written scope, not a proposal designed to sound inevitable.
| Question | What we examine | What you get |
|---|---|---|
| What task? | The decision or transaction the system must support, and who performs it today. | One-sentence purpose, agreed in writing. |
| What exists? | Current tools, spreadsheets, exports, manual steps and the cost of each. | System inventory with owners. |
| What constrains? | Deadlines, contracts, data residency, integrations that cannot change. | Constraint list, marked fixed or negotiable. |
| What is assumed? | Everything we would otherwise quietly believe. | Assumption register — the most useful page. |
| What next? | Build, buy, configure, or stop. | Recommendation with the reasoning shown. |
02Model
Entities, states and exceptions — in words first.
The model is the expensive part to change. It is agreed as a document, with the awkward cases named, before an interface exists to argue about.
E-01Casestates: draft → submitted → approved → closed
E-02Partycan hold more than one role
E-03Approvalimmutable once granted
E-04Exceptionrequires reason + approver
X-01Split caseopen question — who owns the remainder
Open questions are listed with their owner and the date they must be answered. They are not hidden in a backlog comment.
03Build
Increments you can use, not slides you can admire.
Each increment ends in a preview environment with real-shaped data, a short written note on what changed, and a decision: continue, adjust, or stop.
Each cycle
Build
Code, tests and migration in one branch; no unreviewed schema drift.
Each cycle
Show
Watching the people who will use it, in the environment, not in a screenshot.
Each cycle
Record
What changed, what was decided, what was deferred and why.
Each cycle
Decide
Continue, adjust or stop — a stop decision is documented like any other.
Cadence is agreed per engagement. This page deliberately publishes no week counts: they would be invented before your scope exists.
04Release
Cut-over is a checklist, not a Friday.
Real records move once. The checklist exists so that the day is boring.
| Before | During | After |
|---|---|---|
| Rehearsal | Migration runs against a production copy; counts reconciled. | Discrepancy report signed off by a named person. |
| Access | Roles switched, shared logins retired, sessions invalidated. | Access register dated and stored with the runbook. |
| Rollback | Written step, tested once in staging, with a time estimate. | Decision threshold: what would make us use it. |
| Monitoring | Alerts routed to a person, not a group inbox. | First-week review of errors and slow paths. |
05Handover
What we need from you, and what you keep.
Projects stall on access and decisions far more often than on code. Naming both sides up front is the cheapest schedule protection available.
From you
- One decision-maker who can say yes, and one person who knows how the work is done today.
- Access to the systems we must integrate with, in a test or sandbox state where one exists.
- Cloud, domain and repository accounts in your organisation, with permission for us to work inside them.
- An answer within the agreed window on open questions; unanswered questions stop the slice that depends on them.
- Realistic sample data — anonymised if it contains personal information.
From us
- Written artefacts at every stage, in language a non-engineer can challenge.
- No account, credential or licence held in our name.
- A runbook someone else can follow, and a walkthrough of it with your team.
- A documented exit: what you own, where it lives, and what stops working if we leave.
06Change
Scope changes. Pretending otherwise is what breaks projects.
Change 01
Written, then priced
A change request states what is different, why it appeared, what it displaces, and what it costs in time or money. Verbal changes are noted and then either written or dropped.
Change 02
Something is displaced
New work is rarely free. If the deadline is fixed, the displacement is scope; if scope is fixed, the displacement is the date. Both are your call, made with the trade-off visible.
Change 03
Stop is a legitimate outcome
If discovery shows a configuration of tools you already own will do, we will recommend that and document why. A short project that ends early is cheaper than a long one that should have.
Next step
Scope before
estimate.
Send the task, the systems it touches and the deadline you are working to. The first reply is a set of questions, not a quote.