ByAhsan NadeemLead Full-Stack Engineer
Most software projects that go over budget don't fail in the code. They fail in the first two weeks, when nobody wrote down who the users are, what "done" means, or what's deliberately left out. A good scope fixes that, and it doesn't need to be long. It needs to be specific.
This guide walks through what to include, with a template you can copy into a document and fill in. Send it to two or three vendors and you'll get quotes you can actually compare.
Scope vs specification vs RFP
Document | What it answers | Who writes it |
|---|---|---|
Scope (project brief) | What we're building, for whom, and why | You, ideally with your team |
Specification | Exactly how each part behaves | Usually the vendor, during discovery |
RFP | How vendors should respond, and how you'll choose | You, when comparing several vendors |
You don't need a full specification to get a good quote. A clear scope plus a short paid discovery phase works better than a 60-page document written before anyone has questioned it.
The template: what to put in each section
Section | What to write | Example |
|---|---|---|
1. Background | The business, the problem, why now | "Our sales team tracks leads in spreadsheets and loses follow-ups." |
2. Goals | Two to four measurable outcomes | "Every lead gets a first response within one working day." |
3. Users | Who uses it and what each needs to do | "Sales reps, team leads, an admin." |
4. Core journeys | The key tasks, step by step | "A rep logs a call, sets a follow-up, gets reminded." |
5. Features, prioritised | Must / Should / Could / Won't | "Must: lead list. Could: email sync." |
6. Integrations | Systems it must talk to, with links to their docs | "Read contacts from HubSpot; send email via our domain." |
7. Non-functional needs | Security, speed, availability, accessibility, languages | "Two-factor sign-in; works on mobile." |
8. Data | What data exists, what moves, who owns it | "Import 12,000 leads from CSV." |
9. Out of scope | What you're deliberately not building now | "No mobile app in phase one." |
10. Constraints | Budget range, deadline, tech or hosting rules | "Live before the March trade show." |
11. Success and acceptance | How you'll decide it's done | "Team uses it daily for two weeks without spreadsheets." |
Writing requirements people can't misread
Describe outcomes, not screens
"A dashboard with three charts" invites a vendor to build three charts. "Team leads can see, every Monday, which reps have overdue follow-ups" invites them to solve the problem, maybe with a simple list and an email instead of a dashboard.
Use user stories with acceptance criteria
A short format that works well:
As a sales rep, I want to set a follow-up date on a lead, so that I'm reminded before it goes cold. Done when: the reminder appears in my list on that date, and I get an email at 9am.
Prioritise with MoSCoW
- Must: without it, the product doesn't work.
- Should: important, but there's a workaround for launch.
- Could: nice to have, if time and budget allow.
- Won't (this time): agreed to be out of this phase.
Ask vendors to price the Musts as phase one and the rest separately. You'll see straight away what the core really costs.
The section most briefs skip: out of scope
Writing down what you're not building feels unnecessary until the arguments start. Typical items worth listing explicitly:
- Native mobile apps (if a responsive web app will do for now).
- Migrating old data beyond a defined import.
- Integrations other than the ones listed.
- Content writing, translation or photography.
- Ongoing support after the warranty period, which belongs in a separate agreement.
Sending it out: a mini RFP
If you're comparing vendors, add a short section telling them how to respond, so the proposals are comparable:
- Their understanding of the problem, in their own words.
- A module-by-module estimate with assumptions.
- The team who would do the work, with relevant examples.
- How they test, review code and deploy.
- Their proposed engagement model and payment schedule.
- Questions they need answered before committing to a price.
Then score each proposal the same way:
Criterion | Weight | What good looks like |
|---|---|---|
Understanding of the problem | 25% | Restates your goals and challenges your assumptions |
Estimate quality | 20% | Broken into modules, with assumptions and risks named |
Relevant experience | 20% | Similar products they can show and explain |
Engineering practice | 15% | Tests, code review, CI, documentation, handover |
Communication | 10% | Clear writing, quick and specific answers |
Price and terms | 10% | Fair, transparent and tied to milestones |
Notice that price carries only part of the weight. The cheapest proposal that misunderstands the problem is the most expensive one you can pick. Our guide to fixed price vs time and materials explains how to compare the commercial side.
How long should a scope be?
For most business applications, two to six pages. If yours is growing past ten, you're probably specifying screens and edge cases that are better worked out in a paid discovery phase with the team that will build them.
Frequently asked questions
Should I pay for a discovery phase?
Usually, yes. One or two weeks of paid discovery turns a scope into a data model, key designs and a module-by-module estimate. It reduces risk for both sides, and you own the output even if you choose another vendor to build.
Can I get an accurate quote without a detailed specification?
You can get an accurate range. A precise fixed price needs more detail, which is exactly what discovery produces.
What should I do if vendors' quotes are wildly different?
Compare their assumptions, not just their totals. Very different numbers usually mean they understood the scope differently. Ask each to explain what's included in their price.
Should I share my budget?
A range helps. Vendors can then propose what's achievable within it, instead of guessing and pricing the wrong product.
Do I need to choose the technology?
Only if you have a reason, such as an existing system or in-house skills. Otherwise, describe your constraints and let vendors justify their choice.
Want help turning an idea into a scope? We run short discovery phases that end with a data model, designs for the key screens and a module-by-module estimate. See how we estimate in our SaaS MVP cost breakdown, or book a free consultation.
