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. Use them on your next project with any supplier, including one that isn't us.
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 you don't pay.
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. Take it to another supplier if you would rather: a written done-test is the cheapest protection available to you whoever you hire.
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, because the point is that you never have to take a large risk to find out whether we are any good.
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 1. 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.
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. 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.
10. What success looks like
Two or three measurable statements about the world after launch. These seed the done-test.
Done-Test
Download .mdTemplate, version 1. 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.
The rules (read before writing)
- Every check must be demonstrable in a live demo. If it cannot 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.
- Both sides sign. A well-written done-test makes a guarantee payout structurally impossible; that is the point of writing it.
Functional checks
| ID | Check (demonstrable statement) | How demonstrated | Depends on (input + date) | Pass |
|---|---|---|---|---|
| F1 | A user can [action] and sees [result] | Live on staging | none | |
| F2 |
Quality gates
| ID | Check | How demonstrated | 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 |
Performance and economics checks
| ID | Check | How demonstrated | Pass |
|---|---|---|---|
| P1 | [Operation] completes in under [N] at [volume] | Timed live | |
| P2 | [Feature] unit cost at [volume] is at or under [£X per unit] | Billing/metrics shown |
Compliance checks (where applicable)
| ID | Check | How demonstrated | Pass |
|---|---|---|---|
| C1 | Personal data flows match the data map; retention and deletion work as documented | Live walkthrough |
Handover checks
| ID | Check | How demonstrated | Pass |
|---|---|---|---|
| H1 | Client holds source, documentation, and deploy access | Access verified live |
Sign-off
| Client | Mangrove | |
|---|---|---|
| Name | ||
| Date | ||
| Version of this done-test |
Why we publish it
We quote a fixed price against a signed done-test and carry the delivery risk: we deliver it in full, or you don't pay. 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.
It is also the cheapest protection available to you whoever you hire. Ask any supplier to write the test before they quote. What comes back, and how quickly, tells you most of what you need to know.
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. Led a ransomware defence company. 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.