Every engagement runs in five stages, and each one ends in something you can inspect.
From your first message to the end of support, you know which stage you are in, what you will receive and what comes next.
Why the process is written down
We write the process down so you can hold us to it. Each stage ends with a document or a release you can inspect, and the next stage waits until you have it. That protects you from drifting scope, invoices you cannot trace to work and a system only its builders understand.
A project rarely goes wrong in the code first. It goes wrong in an unwritten assumption, a change agreed in a corridor or a deadline that moved quietly. Written records close those gaps.
The five stages
You write to us
Tell us what you need built or fixed. We reply within 2 working days. The stage ends when we agree a discovery scope, or say the work does not fit us.
Discovery
In 1 week we read your documentation, interview the people who run the current process and write the specification. The stage ends when you hold that document, which you can take elsewhere.
Fixed-scope proposal
We quote against the specification: scope, price, timeline and what counts as done. The stage ends when you sign both documents. Later changes go through a written change request.
Build and review
Work ships to staging every 2 weeks, and you test each increment against the acceptance criteria. A progress note arrives every week. The stage ends when the full acceptance suite passes and you sign off.
Go-live, handover and support
We run the acceptance suite and go live with a written rollback plan. You receive the repository, documentation and credentials. We fix defects found in the first 30 days at no charge. Then the stage ends, and maintenance is optional.
What you receive at each stage
After you write to us
A written reply with our questions, then a proposed discovery scope after the first call.
After discovery
The written specification: what the system does and does not do, the data it holds, who can do what and the acceptance tests it must pass.
After the proposal
A signed proposal: scope, price, timeline and what counts as done.
During build and review
A staging release every 2 weeks and a progress note every week. Code and tests sit in your repository from day one.
At go-live and handover
The rollback plan, the repository, every credential, architecture notes, a runbook, a setup guide and a recorded walkthrough.
What the documents look like
Three of the documents named above, in the form you would receive them. The project, the names and the figures are invented to show the format.
Specification excerpt
4.2 Approve a payment batch
An approver reviews a prepared batch and approves or rejects it as a whole. The person who prepared a batch can never approve it.
Rules
- A batch is approved or rejected whole. There is no partial approval.
- Approval limits come from the approver's role. A batch over the limit needs a second approver.
- Every approval, rejection and refused attempt is written to the audit trail.
| ID | Given | When | Then |
|---|---|---|---|
| AT-4.2-01 | A prepared batch of 12 payments | An approver who did not prepare it opens it | They can approve or reject the batch |
| AT-4.2-02 | The same batch | The person who prepared it opens it | No approve button is shown. The attempt is logged. |
| AT-4.2-03 | A batch above the approver's limit | They approve it | The batch moves to awaiting second approval |
Out of scope
- Editing a payment after approval.
- Scheduling a batch for a future date.
Weekly progress note
Week 6
Shipped
- Batch approval, sections 4.1 to 4.3. Acceptance tests AT-4.1-01 to AT-4.3-04 pass on staging.
- Audit trail search by user and date range.
Blocked
- Bank test account not yet issued. Owner: client finance lead. Needed by Tuesday to hold the week 8 date.
Next
- Bank file export, section 5.1.
- Second approver flow, section 4.4.
Decisions recorded
- D-019: rejected batches return to the preparer with the reason. Agreed on Thursday's call, confirmed by email.
Reconciliation report
Migration dry run 2
| Entity | Source | Target | Difference |
|---|---|---|---|
| Customers | 18,412 | 18,412 | 0 |
| Open invoices | 2,947 | 2,947 | 0 |
| Payments | 61,305 | 61,302 | 3 rejected |
| Total | Source | Target | Difference |
|---|---|---|---|
| Open invoice value | 48,210,664.50 | 48,210,664.50 | 0.00 |
| Payment value | 391,774,120.25 | 391,702,870.25 | 71,250.00 |
3 payments were rejected because the customer reference is missing in the source. They are listed in the rejects file with reasons. The payment total differs by exactly their value. Not cleared for switchover until the client corrects or writes off the 3 records.
What we need from you
A fixed scope needs four things from your side.
First, one named decision maker who signs the specification, approves change requests and accepts releases. Second, access to the people who run the current process. They know the exceptions nobody wrote down.
Third, realistic test data, with personal details removed where law or policy requires it. Fourth, a review of each staging release within 5 working days, while problems are cheap to fix.
How changes are handled
Changes start in writing
Either side can raise a change request. It states the change, the reason and the part of the specification it affects. We build nothing from a conversation alone.
We re-quote before we build
We reply with the effect on price and timeline. You approve it in writing or drop it. An approved change joins the specification with its own acceptance tests.
When a deadline moves
The next progress note gives the cause and the new date. If the delay is ours, the price stays fixed. If it comes from late access, data or review, the timeline moves by the time lost.
The numbers
Every number on this page, in one place.
- First reply
- Within 2 working days
- Discovery
- 1 week
- Staging releases
- Every 2 weeks
- Progress note
- Every week
- Your review of each release
- Within 5 working days
- Defect fixes at no charge
- First 30 days after go-live
Questions about the process
Can we skip discovery if we already have a specification?
No, but the week changes shape. We test your document against the people and systems involved and fill the gaps. We only fix a price against a specification we have checked.
What happens if a release is not what we expected?
You tell us in writing, against the acceptance criteria. If the release fails a criterion, we fix it within the fixed price. Anything the specification does not say becomes a change request.
What if the project is too large for one fixed scope?
We split it into phases. Each phase has its own specification, proposal and handover, so you can stop after any phase with working software.
Related pages
Services
The three service lines and what each delivers.
Questions and answers
Cost, contracts, ownership and support after launch.
About
How we think about software and where we work.
Tell us what you need built or fixed, and we reply within 2 working days.
Start a project