A requirements specification that protects your budget
Before a rebuild or a tender, write down what the tool must do, and what it must no longer do.
Who decides what gets delivered?
Without a requirements specification, every provider prices the project they imagine.
You ask for three quotes and receive three different projects. One includes moving the data across, another does not. One plans for hosting, another leaves it to you. You are not comparing prices, you are comparing misunderstandings.
During the project, whatever was not written down comes back as extra quotes. At delivery, nobody can say whether the tool is finished, because "finished" was never defined. And when you replace an existing tool without writing anything down, you rebuild its flaws too: the same data keyed in twice, the spreadsheet kept on the side, the export someone corrects by hand every week.
Who writes the specification? If you have a technical team, they are often taken up by current projects and day-to-day requests: it comes last, or gets written in a hurry. We write it alongside them, not instead of them: they know the tool, we take the time to put everything in writing.
When do you need one?
-
Before a rebuild
To rebuild what you need today, not what the tool did ten years ago.
-
Before a tender
So that every offer answers the same question, and the offers can be compared line by line.
-
Before changing provider
So that the new provider knows exactly what they are taking over, and what you expect of them.
What it contains
A precise document that any provider can put a price on.
- Context and goals: why the project exists, what it must change, and how you will know it has worked.
- Users and roles: who uses the tool, to do what, with which rights.
- Processes: how the work is done today, and how it will be done tomorrow.
- Functional requirements: what the tool must do, task by task, ranked by priority.
- Data and migration: what exists, where, in what state, and what must be carried over.
- Integrations: your accounting, your website, your suppliers' and partners' APIs, the files you exchange.
- Non-functional requirements: security, availability, hosting, GDPR.
- What the tool must no longer do: the same data keyed in twice, the workarounds, the features nobody uses any more.
- Acceptance criteria: how to check, at delivery, that the tool does what was asked.
- Deliverables: the application, its source code and its access credentials, and when each one is handed over.
- Documentation and handover: what must be written down so that another team can take the tool over one day.
- Reversibility: the source code, the data, the hosting and the domain name in your name, so you can change provider without starting from scratch.
The health check first
A specification written from memory describes the tool as people think it works.
The health check describes the tool as it really works: one hour with management, one hour with the people who use it every day, a reading of the code and the hosting. It also measures the gap between how management believes the tool is used and what the team actually does.
Its findings become the starting point of the specification: the data to carry over, the integrations to keep, the workarounds to remove, the priorities with figures attached. The health check tells you what the rebuild must contain, and what the current tool costs you until then. You decide with figures, not under the pressure of an outage.
So when the specification prepares the replacement of an existing tool, we start with the health check. For an entirely new tool, we start from your processes.
A fixed price per phase
We work at a fixed price. The work is split into phases, each with its own fixed price, announced before it starts. You know what you are committing to at every step.
The document belongs to you: you can hand it to the provider of your choice. Once the offers are in, an independent review helps you compare them.
Frequently asked questions
How many pages is a requirements specification?
The number of pages depends on the tool, not on a template. What matters is that every provider can price it without guessing: who uses the tool, what it must do, the data to carry over, and how to check at delivery that everything is there.
Do I have to describe the technical side myself?
No. You explain your work to us: who uses the tool, to do what, and where it gets stuck today. We write the technical parts (the data, the integrations, security, hosting). If you have a technical team, we write them alongside it.
Can I send it to several providers?
Yes, the document belongs to you. Sent to several providers, it asks them all the same question: their offers cover the same project, and you finally compare prices. To choose between them, see the independent review.
A project to prepare?
A rebuild, a tender, a change of provider: talk to us before you commit.
The self‑assessment: ten questions about your current tool, your score straight away.