What a client-ready scoping document looks like
Before the first line of code, I deliver a scoping document the client can actually use. Structure, lots, validation criteria: here's what is inside.
The first deliverable is not time, it is clarity
When a client hires a freelancer, they often think they are buying development days. In my process, the first deliverable is a scoping document the client can use immediately.
Its job is to lock a shared reading of the project before code turns misunderstandings into expensive realities.
The five blocks the client actually gets
- The product promise in one sentence.
- The list of delivery lots with the scope of each.
- Validation criteria for every lot.
- The chosen technical architecture.
- The key decisions with their rationale.
How a lot is written
The client does not need a list of broad intentions. They need blocks that can be validated. A lot should state what is in, what is out, and how we know it is done.
On Grimoire, lot 8 was written as a full auth block, not as a vague instruction like 'do auth'. That precision is what makes validation possible.
What this changes on the client side
The main benefit is predictability. The client sees where the project is going, in what order, and on which basis each delivery can be validated.
Scope creep becomes more visible. End-of-sprint surprises decrease. Budget and timeline discussions become more concrete because they are tied to delivery units, not feelings.
What happens after each lot
The document does not disappear once development starts. It evolves. Each lot then goes through tests, a post-delivery audit, and a scoping update if an important decision changed.
What the client buys, in the end, is not only code. It is a project that stays readable from the first lot to the last.