Software projects rarely fail because the technology was wrong. They fail because two people meant different things by the same sentence, and nobody found out until money had been spent. We write the spec first because that is the cheapest place to find out.
Where projects go wrong
A brief says “users can invite their colleagues”. The client pictures an email link. The developer pictures roles, permissions and an audit trail. Both read the same sentence and both are right. The gap shows up in sprint six, when the second picture is half built and the first is what was wanted.
Code is the most expensive way to discover a misunderstanding. Every line written on the wrong assumption has to be found, argued over and rewritten. A document is the cheap place to be wrong. Disagreements show up as comments in the margin, not as rework in the repository.
What the spec is
A full technical spec, written before any code. It sets out what will be built, how it will be built and what it depends on. Each of those is a place where a wrong assumption hides.
- What: the behaviour, described so you can check the finished software against it.
- How: the architecture and stack, with the reason a technology was chosen, not just its name.
- What it depends on: third-party services, data you have to supply and decisions that are yours to make.
It also records what is out of scope. A boundary written down on day one is a conversation. A boundary discovered in month three is an argument.
A paid first step, at a fixed price
The spec is a separate piece of work, and it is paid for. The price is fixed and quoted in writing before we start it. You know the cost of the first step before you commit to it, and there is nothing to renegotiate halfway through.
Charging for it changes what it is. A free proposal is a sales document. A paid spec is a deliverable, and someone is accountable for it being right. It also gives you a way to find out how we work before you commit to a build: you see how we ask questions, how we write and how we handle the parts that are still unclear. The details are on the spec page.
Yours to keep
If you read the spec and decide to build elsewhere, the spec is yours. It is written so another team can quote against it and build from it. That is deliberate. We would rather you leave with something useful than stay because we are holding something back. The same principle runs through how ownership works on the build itself.
What it changes in the build
Once the build starts, we work in two-week sprints with a deployable link every Friday, measured against a document both sides have read. When something changes, you can see what it changes against what was agreed, and decide with the cost in front of you.
A spec is not a promise that nothing will change. Requirements move, and good ones should. It is a record of what was agreed, so that a change is a decision and not an accident. That is what we mean by no scope surprises.
When it feels slow
Some people want to start building on day one, and starting without a document does feel faster for the first few weeks. The cost arrives later, as rework, as a feature nobody asked for, or as an argument about what was promised.
We do not start without a written spec. It is on the short list of things we will not do, alongside holding your code and hiding a slipped Friday. The rest of that list is on how we work.
If you have a rough idea and no document, that is the right place to begin. Start a project, send the context however rough it is, and we reply within 24 hours, on working days.