To scope a software project, write down who uses it first, the one thing they must be able to do, the screens that takes, the hard parts, and the list of what version one will not do. You don't need a CTO for that part. One page of plain English beats a 30-page document nobody reads.
Most owners skip this and ask three developers to quote "an app like Uber for my cleaning crews." They get three wildly different numbers, because each developer quietly scoped a different app in their head. Scoping first is how you get quotes you can actually compare.
Key Takeaways
- Scope is a written decision about version one: one user, one job, a short list of screens, and an explicit list of what's left out.
- The out-list controls cost more than the in-list. Every feature you defer is money you keep until you know it's needed.
- If two developers read your scope and quote roughly the same thing, it's done. If their questions go in completely different directions, it isn't.
- You can draft a first scope for free with Sol's Honest Read, then hand it to any developer.
How to Scope a Software Project in Five Questions
Answer these in order, in writing. Saying them out loud in a meeting doesn't count.
1. Who is the first user? Pick one. "My dispatchers" is a user. "Everyone in the company" is a wish.
2. What is the one thing they must be able to do? Finish the sentence: "On day one, a dispatcher can ___." If you can't finish it in one line, you have two projects.
3. What screens does that take? Draw boxes on paper. Most first versions land between 3 and 7 screens. Login, a list, a detail view, a form and a settings page is already five.
4. Where are the hard parts? Usually payments, connecting to another system (QuickBooks, your scheduling tool, an old database), anything that must work offline, anything real-time, and anything touching health or financial records. Name them. Developers price the hard parts, not the screens.
5. What is out of version one? Write at least three things. Reports, a mobile app on top of the web app, a customer portal, multiple languages, detailed roles and permissions.
Owners resist that last question because cutting feels like losing. I'd argue the out-list is the most valuable line on the page. We wrote a whole piece on what to leave out of the first version of your app; the short version is that a deferred feature costs nothing until you prove you need it.
What a Scope Is For
| A scope is | A scope is not |
|---|---|
| One or two pages a developer can quote from | A requirements document listing every field and rule |
| A decision about version one | A three-year roadmap |
| Written in your words | Written in jargon you'd have to fake |
| The basis for a fixed price or a time estimate | A contract on its own |
Once a developer is involved, they'll turn your scope into something more detailed. That's normal. A software requirements document or a spec for a developer comes later and goes deeper. Your job is to decide what, so their job can be how.
Where Sol Fits
If the blank page is the blocker, start with the Honest Read. Sol asks a few questions, one at a time, then writes a read with nine fixed sections: what you're building, who uses it and the one thing they must be able to do, the screens (3 to 7), the hard parts, what to leave out of version one, three ways to get it built with real cost ranges, a verdict, two questions to answer before you spend a dollar, and a short spec any developer can quote from.
You'll notice that's the five questions above with a verdict attached. On purpose. Scoping takes a willingness to decide far more than it takes technical skill. Any email works for the read, and it's yours to hand to any developer, including one who isn't us.
A Concrete Version
A landscaping company with 14 crews wants an app so crew leads stop texting the office photos of finished jobs.
- First user: crew leads.
- The one thing: on day one, a crew lead can mark a job done and attach photos, and the office sees it.
- Screens: login, today's jobs, job detail with photo upload, office view of completed jobs. Four.
- Hard parts: photos on weak cell signal (uploads need to wait and retry), and pulling the job list from the scheduling tool they already pay for.
- Out of version one: customer notifications, invoicing, time tracking, a manager dashboard.
The owner sends that page to two developers. One estimates about 160 hours. The other estimates about 200 hours and asks a sharp question about the scheduling tool's export. Those are close enough to compare. At an assumed $45 an hour (illustrative, inside the $25 to $49 range Clutch gives for app development companies), that's $7,200 against $9,000.
Before writing the scope, the same owner had collected quotes of $8,000 and $60,000 for "a crew app." Nobody, including the owner, knew what was in it.
The Honest Counterpoint
A scope written by someone non-technical has blind spots. You may not know that your scheduling tool can't export jobs at all, which turns a two-day task into a two-week one. Paper won't show you that.
So treat your scope as a first draft a developer is allowed to push back on. Good ones will. If someone quotes your scope without asking a single question, be wary: either they didn't read it, or the surprises will show up later as change orders.
And if the project is big (several kinds of users, regulated data, replacing a system your whole company runs on), pay for a proper discovery phase. A one-page scope fits a first version. It won't carry a rebuild of your ERP.
Frequently Asked Questions
How do I scope a software project if I'm not technical?
Answer five questions in writing: who the first user is, the one thing they must do on day one, the screens that takes, the hard parts, and what's out of version one. Send that page to two developers and compare their questions as much as their prices.
How long should a project scope be?
For a first version, one or two pages. Longer than that and you're probably writing requirements, or planning version three.
What's the difference between scope and requirements?
Scope decides what version one does and doesn't do, and the owner owns it. Requirements describe how each piece behaves in detail, and they usually get written with the developer.
The Bottom Line
Scoping is a decision, and you're the person who has to make it. Put the one user, the one job, the screens, the hard parts and the out-list on a single page. For a head start, get an Honest Read from Sol: you get that page plus a verdict on whether you need a developer at all. Here's how the Honest Read works, and when you're ready to build at a fixed price, see the software factory.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers, with a vetted shortlist in 72 hours. See available engineers.
