Free · No email required
What “done” means, in writing, before anyone quotes a price.
You are about to commission a build, or you are in one and uneasy, or you have three quotes that are impossible to compare. All three come down to the same missing document. A feature list says what will be built. It never says how anyone will know it was built properly, and that gap is where the money goes.
The done-test closes it: a plain list of checks that can be shown working, agreed and signed by both sides before a price exists. It is what our money-back guarantee pays out against, so we write it to be binary.
Both templates are below, in full, free to download. No form, no gate. Fill them in and you have the document we quote a fixed price against.
These templates will tell you which one you are
Open them and try to fill them in. Whether you can is the whole diagnosis, and you can run it on yourself in twenty minutes without speaking to anyone.
You know what you want
Fill them in, and the price comes back fixed
If you can complete the spec and the done-test for the thing you have in mind, you are ready to buy a build. Send them over and you get a fixed price quoted against exactly those checks, delivered in full or your money back.
Start small if you would rather: a first fixed-price piece under £6k carries the same signed done-test and the same money back as a full build.
You know something is wrong, not what to buy
Then the writing is the work
Most people arrive here. A short paid shaping pass turns what you know into the spec, the done-test and one fixed price. It is the same document, written together instead of alone.
The output is yours whether or not we build it, and it is the same document the fixed price and the guarantee are written against.
Four properties, or it is not a test
Demonstrable
Every check can be shown working in a live demo. If it cannot be shown, it cannot be in the done-test.
Skip it and nobody can tell you whether you have the thing you bought. That is the argument, six months in.
Binary
Adjectives are banned. Fast, easy and intuitive are opinions; a number is a test. There is no partial pass.
An adjective cannot fail, so it cannot pass. Every “fast” in a contract is a dispute with a delay on it.
Dependency-aware
A check waiting on something from your side is blocked, not failed. Blocked items are completed late, waived in writing, or severed at acceptance.
Without it, their late delivery becomes your fault or your late input becomes their excuse, and neither side can prove which.
Signed by both sides
It is written together and signed before a price exists, so the price is quoted against something real.
Without it you are trusting one party's reading of a feature list, and a reading is not something either of you can hold the other to.
The same requirement, twice
Everything in the left column has appeared in a real software contract. None of it can fail, which means none of it can pass.
| Written in most contracts | Written as a test |
|---|---|
| The search is fast | Search returns in under 500ms against 10,000 records, timed live |
| The application is secure | SAST and dependency scanning run in CI on every commit with no unresolved critical findings, shown in a CI run |
| Documents upload reliably | A 200MB scanned PDF uploads, is virus-scanned and appears in the record; a failed upload retries and surfaces an error to the user |
| The AI feature works | Answers cite their source document; unit cost at 5,000 queries per month stays at or under the agreed figure, shown from billing metrics |
| Handover is complete | You hold source, documentation and deploy access, verified live on your own account |
A worked example
A six-figure contract is sitting in procurement waiting on one capability: enterprise single sign-on. Most contracts would describe it as “SSO support”, which is not a sentence you can hold anyone to. Here is the same capability written as checks. Illustrative rather than a client document, and short on purpose; a full one runs to a few pages.
| ID | Check (demonstrable statement) | How demonstrated | Depends on | Pass |
|---|---|---|---|---|
| F1 | A user signs in through the customer's Okta tenant and lands on the dashboard with their role applied | Live on staging against the customer's sandbox tenant | Sandbox tenant credentials, 12 March | ☐ |
| F2 | A user removed in Okta cannot sign in, and their active session ends within 15 minutes | Live, timed | none | ☐ |
| Q1 | Automated tests cover F1 and F2 and run in CI on every commit | CI run shown live | none | ☐ |
| C1 | The audit log records every sign-in, role change and failed attempt, exportable as CSV over a chosen date range | Live walkthrough plus an exported file | none | ☐ |
| H1 | Your team holds source, setup documentation and deploy access for the SSO integration | Access verified live on your account | none | ☐ |
Note F2. Nobody asks for it, and it is the check the buyer's security reviewer cares about most. Writing the done-test is when that surfaces, which is why the writing comes before the price rather than after it.
If you have something you are about to commission, we will write the first few checks with you on a call and you can take them away.
What happens after the document exists
- 1
You fill in the spec and the done-test, or we write them with you in a paid shaping pass.
- 2
Both sides sign the done-test. Only then does a price exist.
- 3
Start with a piece small enough to be a cheap test of us, on the same terms as a large one.
- 4
We ask for bigger commitments after we have earned them.
The guarantee runs the whole way down that list. A first piece under £6k carries the same signed done-test and the same money back as a full build.
The templates
These are the working versions, not a marketing edit of them. The spec describes what you want; the done-test describes how both sides will know it arrived.
Requirements Document
Download .mdTemplate, version 2. How to use it: fill in every section; write "none" rather than leaving blanks. Short is fine, vague is not. This document plus the done-test is what a fixed price is quoted against; the sharper they are, the lower the shaping cost (a fully done-test-ready pack can take it to zero).
1. The product in one paragraph
What it is, who it is for, and what changes for them when it exists.
2. Goals and non-goals
- Goals: the two or three outcomes this build must achieve.
- Non-goals: what this build deliberately does not attempt. Non-goals prevent scope drift better than any meeting.
3. Users and surfaces
Who uses it (roles, not personas essays) and where (web, mobile, admin, API consumers).
4. Scope
| In this build | Out (explicitly) | Later (parked) |
|---|---|---|
One row per feature, in plain language. Anything not written here is out.
5. Assumptions
List every assumption you are making. Each one moves the price when it turns out false, so surfacing them now is money.
6. What you will provide, and by when
| Input (content, access, approvals, third-party sign-offs) | Needed by |
|---|---|
These become named dependencies in the done-test. Work blocked on a missing input pauses the clock; it does not fail the build.
For AI features, the labelled evaluation set belongs here, with an owner and a date. It is on the critical path: it is what "done" is measured against, and it has to come from real data rather than examples written for the purpose.
7. Integrations and data
Systems to connect to, data in and out, who owns each source, and any migration from existing systems.
8. Constraints
- Regulatory and compliance: GDPR posture, sector rules, audit requirements, data residency.
- Technical: required stack, hosting, existing systems that must be respected.
- Commercial: budget band, hard dates and what drives them.
9. Non-functional requirements
Put a number against every line that applies and write "not required" against the rest. These become the non-functional rows of the done-test, and an omission here is a decision: what is not specified is not built, and not refundable.
| Requirement | |
|---|---|
| Load and concurrency | Expected and peak concurrent users; the operation that will be busiest |
| Response time | The slowest acceptable response for the operations that matter, at p95 |
| Availability | Target uptime, the hours it applies to, and what an outage actually costs you |
| Recovery | How much data you can afford to lose, and how long you can be down |
| Accessibility | Target standard (WCAG 2.2 AA is the usual answer) and whether an audit is required |
| Browsers and devices | The matrix you support, and the oldest thing that must work |
| Observability | Who gets told when it breaks, by what route, and how fast |
| Security posture | Authentication model, roles, and whether a penetration test is in scope |
| Data residency | Where data may be stored and processed |
Design and brand. Where the look matters, name the approved frames or design system and say who signs them off. Taste is approved before the build; only compliance with the approved design is testable after it. A done-test cannot hold "looks good", so the approval has to happen upstream.
10. Run economics
For anything with a material running cost (AI features, third-party APIs, data volumes): expected volumes and the unit cost that must hold at those volumes. A feature that works but is uneconomic to run is a failed feature; this section is where that gets caught before it is built.
11. What success looks like
Two or three measurable statements about the world after launch. These seed the done-test.
Done-Test
Download .mdTemplate, version 2. The done-test is the contract: an objective, demonstrable definition of "done" that both sides sign before a fixed price exists. It is what the money-back guarantee pays out against, so it is written to be binary.
Keep this core short. Rows specific to what you are building come from the check libraries: web application, front-end and design, AI agents, bots, standalone applications, data and integration. Take the rows that apply, delete the rest.
The rules (read before writing)
- Every check must be demonstrable, and the evidence named. Acceptable evidence is a live demo, a CI run, a recorded drill, a metrics or billing dashboard, or a third-party report. If nobody can say how a check would be shown, it cannot be in the done-test.
- Binary, not adjectival. "Fast", "easy", and "intuitive" are banned; write the number instead ("search returns in under 500ms at 10,000 records").
- Client-dependent checks name their input and date. A check waiting on something from your side is blocked, not failed; blocked items are completed late, waived in writing, or severed at acceptance.
- Material run costs get an economics check. If a feature costs money per use, the acceptable unit cost at production volume is a pass/fail row.
- Changes go through a written change request, producing a revised price and done-test. Verbal additions are not scope.
- Ambiguity is a defect in the test, not a matter for negotiation later. If a check could be argued either way on the day, it was not objective enough to sign. Rewrite it before signing, not after.
- Both sides sign, and every revision is logged at the end of this document.
What happens when a check misses
Agreed before signing, so nobody is negotiating it at the demo.
| Situation | What happens |
|---|---|
| A check fails at the demo | Fixed at our cost until it passes. Cure comes first; the refund is for the case where it cannot be cured. |
| A check is blocked on a client input named in the table | The clock pauses. At acceptance it completes late, is waived in writing, or is severed from the assessment. |
| Delivery cannot reach the signed done-test | That stage's fee is refunded in full, and that stage's work, code and IP revert. Prior accepted stages are untouched. |
| Something is wanted that is not in the table | Written change request, revised price, revised done-test. |
Conditions of the demo
Fill this in. Half of all acceptance arguments are about the conditions rather than the checks.
| Environment the demo runs in | |
| Data used (and how representative of production) | |
| Acceptance window after the demo | |
| Who attends and who signs |
Functional checks
| ID | Check (demonstrable statement) | Evidence | Depends on (input + date) | Pass |
|---|---|---|---|---|
| F1 | A user can [action] and sees [result] | Live on staging | none | |
| F2 |
Quality gates
| ID | Check | Evidence | Pass |
|---|---|---|---|
| Q1 | Automated tests exist for the functional checks above and run in CI on every commit | CI run shown live | |
| Q2 | Security scanning (SAST + dependency scan) runs in CI with no unresolved critical findings | CI output shown | |
| Q3 | Documentation covers setup, deployment, and operations | Repo walkthrough |
Non-functional checks
Delete any line that does not apply to this build, and put a number in every line that does. These are the four hardening layers a production-grade delivery is scoped against; the ones you keep are the ones you are buying.
| ID | Check | Evidence | Pass |
|---|---|---|---|
| N1 | [Operation] completes in under [N] at [volume], measured at p95 rather than mean | Timed live | |
| N2 | System sustains [N] concurrent users with error rate under [X]% | Load-test output | |
| N3 | Availability target of [N]% over the warranty period, measured by [monitor] | Monitoring dashboard | |
| N4 | A failure is visible without a customer reporting it: [named alert] fires within [N] minutes and reaches [named recipient] | Alert triggered live | |
| N5 | A backup taken today restores to a working system within [N], losing at most [N] of data | Recorded restore drill | |
| N6 | Meets WCAG 2.2 AA on the primary journey, with zero critical axe findings and the journey completable by keyboard alone | Audit output + live keyboard walkthrough | |
| N7 | [Feature] unit cost at [volume] is at or under [£X per unit] | Billing or metrics shown |
Compliance checks (where applicable)
| ID | Check | Evidence | Pass |
|---|---|---|---|
| C1 | Personal data flows match the data map; retention and deletion work as documented | Live walkthrough | |
| C2 | Every third party that receives personal data is named, with its purpose and legal basis recorded | Sub-processor list |
Handover checks
H2 is the one that decides whether you own the system or merely possess it. Do not delete it.
| ID | Check | Evidence | Pass |
|---|---|---|---|
| H1 | Client holds source, documentation, and deploy access | Access verified live | |
| H2 | A named engineer on the client side, who did not build it, clones the repo, runs the test suite, makes a trivial change and deploys it to staging, unaided, working only from the written documentation | Performed live by that engineer | |
| H3 | Every credential, key and account used in the build is held by the client and rotated at handover | Access verified live |
Sign-off
| Client | Mangrove | |
|---|---|---|
| Name | ||
| Date | ||
| Version of this done-test |
Revision log
Every change to a signed done-test is recorded here, with the change request that caused it.
| Version | Date | What changed | Change request ref |
|---|---|---|---|
| 1 | Original signed version | n/a |
Check libraries, by what you are building
The core done-test above stays short enough to sign. What a good check looks like depends on what is being built, so the rows live here: take the ones that apply, delete the rest, and put a number in every threshold.
AI agents and LLM features
How a probabilistic system gets a binary test: freeze the evaluation set, pin the harness, agree the threshold. Plus cost per operation, escalation, and who re-qualifies when the model is deprecated.
Download .mdFront-end and design
Taste is approved upstream, compliance is tested downstream. Fidelity to signed frames, breakpoints, WCAG 2.2 AA, Core Web Vitals, and the loading, empty and error states a demo skips.
Download .mdWeb applications and platforms
Per-role access proven by attempting what should fail, migration reconciled, a restore actually performed, and deploy, rollback and alerting shown working.
Download .mdBots and conversational interfaces
Install and permission scopes, behaviour under platform rate limits, conversation state surviving a restart, and handover to a human that carries the context.
Download .mdStandalone and installed applications
The upgrade path rather than the clean install, offline and reconnection, signed binaries, crash reporting, and a diagnostic bundle support can actually use.
Download .mdData pipelines and integrations
What happens on the bad day: the malformed record, the duplicate delivery, the source that changed shape, and the run that silently did nothing.
Download .mdWhy we publish it
We quote a fixed price against a signed done-test and carry the delivery risk: delivered in full, or your money back. A promise like that is worth nothing if the thing it pays out against is invisible until you have signed a contract. So here it is, before you talk to us, in the same form we would use on your project.
Anyone willing to write the test before they quote is telling you something, and so is anyone who will not. Ours is above, written before you have spoken to us.
Who wrote this
Kevin Maguire, twenty years as a CTO and CIO. Grew a five-person startup into a payments utility carrying £17bn of flows for the world's largest banks, acquired by Visa. Re-architected a platform handling £24bn a year. CISSP, and CISO at Earthport. The done-test is what twenty years of watching software arguments end badly turned into one page.
That is also the person who does the work now. Every engagement is counted directly from git and published: pages, endpoints, tests, working days.
Start wherever you actually are
Half an hour on a call, or a few bullet points in an enquiry. Both get you the same thing: a straight answer on whether what you want is ready to be priced, and what it would take to get it there.
If you have filled in the templates, send those instead and we'll mark up where the checks are still opinions. Either way there is no obligation, and the reading costs you nothing.