← All tools
Delivery
Spec Decomposer
"I want a contact form" is a brief, not a specification. This tool shows a client what really needs to be specified for a developer to start — without guessing, without going back, without scope creep.
Choose a feature. The tool guides you point by point to build a complete spec, which you can receive by email.
How to use this tool
- 1Choose the feature you want to develop
- 2Discover the specification dimensions to cover
- 3Use this list as a basis for discussion with your team
- 4Compare with your current brief to identify gaps
Why it matters
A developer who receives 'I want a contact form' will make assumptions: about fields, validation, post-submission behaviour, error handling, anti-spam protection, GDPR requirements. Each unaligned assumption generates a round trip, a delay, or a post-launch fix. Specifying upfront halves the number of these round trips.
Frequently asked questions
- Do you really need to specify all these points before starting?
- Not necessarily all of them, but ignoring them without a conscious decision is risky. The goal isn't an 80-page spec — it's identifying the blind spots that will cause blockers or disappointments mid-project. Some points can be decided in 30 seconds of discussion; others require real thought.
- How do you use this tool with a client?
- Show the breakdown at the start of the scoping session to calibrate expectations about what 'simple' really means. Use it as a list of questions to go through together, not a document to fill in entirely. The goal is to open the discussion, not to document everything before starting.
- What is the difference between a specification and a requirements document?
- A requirements document describes the need and context (the what and the why). A functional specification describes the expected system behaviour (the how). Both are useful at different stages: the requirements doc in pre-sales, specs during technical scoping.