How to scope a software project before you write a single line of code
Most software projects fail in scoping, not in coding. A practical guide to defining what to build, what to leave out, and how to keep both you and your developer honest.
The single most expensive mistake in custom software is starting to build before anyone has agreed what is actually being built. Bad scoping shows up later as scope creep, missed deadlines, and the dreaded 'this isn't quite what I had in mind' moment three months in. Good scoping is unglamorous work, but it's the part that determines whether the project lands well. Here's the process we use, in the order we use it.
Step 1: write the business problem in one paragraph, with no technology in it
Before anyone talks about features, frameworks, or screens, force yourself to describe the actual problem in plain language. 'We spend 12 hours a week reconciling invoices between two systems.' 'Our salespeople don't know which leads are hot because the data lives in three places.' 'We're losing customers at checkout because the form is broken on mobile.' If you can't describe the problem in one paragraph without using the word 'app,' you don't understand it well enough to build a solution yet.
Step 2: identify the one user whose life the software needs to improve
Every successful piece of software exists to make a specific person's day better. Name them. The warehouse manager who reconciles stock at 6 a.m. The sales rep who needs to log a call between meetings. The customer who wants to check the status of an order on their phone. Once you know who the software is for, every later decision — what to include, what to cut, how the interface should feel — has a clear answer. Without that, decisions get made by committee and the result satisfies no one.
Step 3: list the workflows, not the features
Features are a trap. They're abstract, they expand without limit, and they don't tell you whether the system actually works. Workflows are concrete: a workflow is a person sitting down to do a specific thing, from start to finish. 'A warehouse manager receives a delivery, scans it, and updates stock.' 'A customer searches for a product, adds it to cart, and pays.' List the five or six workflows the system has to support. Anything that isn't part of one of those workflows is out of scope until version two.
Step 4: separate must-have from nice-to-have, ruthlessly
For each workflow, ask the same question: if this feature didn't exist, could the user still complete the workflow? If yes, it's nice-to-have. If no, it's must-have. The must-haves go in version one. The nice-to-haves go on a list you'll revisit after launch. This is the hardest step, because everyone has favourite features they want to defend. But every nice-to-have you ship in version one is a week you didn't spend on getting the must-haves right.
Step 5: define what success looks like in numbers
Before the build starts, agree on what 'this project worked' means. 'We reduced invoice reconciliation from 12 hours to under 1 hour per week.' 'Sales reps log 90% of calls within the same day.' 'Mobile checkout abandonment drops by 30%.' A project without a success metric is impossible to evaluate. You'll deliver software, the client will use it for a while, and no one will know whether it was worth the money. Set the metric upfront and you'll know.
Step 6: write it down and sign it
Every commitment from the previous five steps goes into a one-page scope document: problem, user, workflows, must-haves, success metrics. Both sides sign it. This isn't bureaucracy — it's the single most useful document you'll have for the next three months. Every time someone says 'can we also add…,' you go back to the document. Either the new request is genuinely critical and worth a formal change, or it's a nice-to-have and goes on the post-launch list.
Why this matters
Software is expensive, and the cost is mostly time. Every week you spend building the wrong thing is a week you don't spend on the right thing. The scoping process above takes a few days. Skipping it costs months. We've never seen a project where time spent on scoping wasn't paid back many times over during the build. The clients we work with longest are the ones who treat scoping as the actual work, and coding as the easy part that follows.