A Founder's Guide to Scoping a Software Project
Before you hire a developer, you need to scope your project properly. Here's how UK founders can do it clearly — even without a technical background.
You've got a clear idea of what you want to build. Maybe it's a client portal, a custom booking system, or an internal tool to replace the mess of spreadsheets your team is working from. You know what problem it's solving. You're ready to get started.
Then you speak to a developer or agency, and they ask: "Can you send us a scope?"
If your stomach drops a little at that question, you're not alone. Scoping a software project — writing down clearly what needs to be built, for whom, and why — is one of the most important steps in any software project, and one of the least talked about for founders without a technical background.
This guide will walk you through it. No jargon. No templates with 47 sections. Just what actually matters.
What "scoping" actually means
Scoping is the process of agreeing, in writing, what a piece of software will and won't do before anyone starts building it.
A good scope protects you. It means the developer builds what you actually need, you don't pay for things that creep in along the way, and there's a shared reference point when questions come up mid-build.
A bad scope — or no scope — is where projects go wrong. Time and money get spent on the wrong things. Features appear that nobody asked for. Features that were assumed go missing. Arguments happen about who promised what.
You don't need to write a 30-page specification document. You need enough clarity that both sides agree on the destination before the journey starts.
Start with the problem, not the features
The most common mistake founders make when scoping is jumping straight to a list of features. "I need a login page, a dashboard, a search function, a reporting section…"
Features are the answer. Before you list answers, make sure you've clearly stated the problem.
Ask yourself: What is this system replacing or fixing, and for whom?
For example: "Right now, my team tracks all client jobs in a shared spreadsheet. It's constantly out of date, two people can edit it at once and overwrite each other, and we have no way of knowing which jobs are urgent. I need a system where my four-person team can log in, see their jobs, update the status, and flag anything that needs attention — and where I can see an overview without having to ask anyone."
That paragraph tells a developer more than a feature list ever could. It explains the context, the users, the pain, and the outcome. Build the scope from there.
The five questions your scope needs to answer
Once you're clear on the problem, work through these five questions. The answers don't need to be long — a few sentences each is fine.
1. Who uses it? List every type of person who will log in or interact with the system. Not by name — by role. "A team member" and "an admin" might have very different access levels and screens. Getting this wrong early is one of the most expensive mistakes to fix later.
2. What are the core things it needs to do? Think in actions, not features. "A team member needs to be able to update the status of a job" is more useful than "status dropdown." Aim for eight to twelve core actions. If you've got thirty, you're probably trying to build too much at once.
3. What does it need to connect to? Does it need to pull data from your accounting software? Send emails or texts? Integrate with your calendar or booking system? Connections to other tools are often the most technically complex part of a build. Name them upfront.
4. What does success look like after six months? Be specific. "My team spends less time updating each other in WhatsApp" is a real outcome. "It's more efficient" is not. Knowing what success looks like helps the developer make good decisions when tradeoffs come up mid-build.
5. What's out of scope for now? This is the question most founders skip, and it's one of the most valuable. Listing what you're deliberately not building in this phase keeps the project focused and prevents scope creep. "We're not building a client-facing portal in this version" is a complete sentence that could save weeks of work.
How much detail do you need?
Enough to have a productive conversation, not enough to design every screen.
A scope document doesn't need to include wireframes, design choices, or technical architecture. It should cover the what and the why. The developer will help you figure out the how.
A useful one-page scope might look like this:
- Background: one paragraph on the business, the problem, and why now
- Users: a bullet list of roles
- Core functions: eight to twelve action-led bullets
- Integrations: any tools it needs to talk to
- Success metric: one or two specific outcomes
- Not in scope: a short list of things being deferred
That's it. You can write it in a Google Doc in an afternoon.
What to do if you're not sure what to scope
Sometimes founders come to us knowing something needs to change but not exactly what to build. That's fine — it's actually more common than having a fully-formed idea.
In those cases, the right first step isn't writing a scope. It's a conversation. A good agency or developer should be able to help you translate "this is the problem we have" into "here's what we'd build to solve it" — and then help you scope from there.
Be cautious of anyone who asks you to write a detailed specification before they've asked a single question about your business. Requirements gathering is part of what you're paying for.
One final thought
The goal of a scope isn't to lock everything down before work starts. It's to make sure you and whoever is building your system are working from the same picture. Things will change as the project progresses — that's normal. But a clear starting point means changes are additions or refinements, not complete redirections.
If you're ready to start thinking about what you'd build, book a free discovery call. We'll help you get from "here's the problem" to a scope you can actually move forward with.