How we scope software projects so they ship
A written plan, a thin first slice, and a demo every week. The habits we use to keep a custom software project honest.
evanbyte4 min read
Most software projects don't fail in the build. They fail before it, when nobody wrote down what 'done' means. Scoping is the cheapest part of a project and the one with the most leverage.
The first call
A good first conversation is mostly questions. These are the ones we ask, and they work as a checklist for any project.
- Who uses this, and what do they do today instead?
- What would make this a success in six months, and how would you notice?
- What can't change: systems you must integrate with, deadlines, compliance rules?
- What has been tried before, and why did it stop?
- Who needs to say yes, and who will be affected but isn't in the room?
What a good scope contains
- The goal, in one paragraph. Who is this for, and what changes for them when it works?
- What's in and what's out. The out list matters most. It's where surprises hide.
- The riskiest assumptions. The two or three things that, if wrong, change the plan. We test those first.
- Milestones you can see. Each one ends with something working that you can try, not a progress report.
- Who decides what. One named person who can say yes, and how quickly we need answers.
Start with a thin slice
A thin slice is one real path through the whole system, end to end: a user signs in, does the one thing that matters, and the data lands where it should. It's rough everywhere and complete in a narrow way. It proves the architecture, exposes integration problems early, and gives everyone something concrete to react to.
Compare that with building layer by layer, where the database is finished in month one and the interface in month three, and nobody knows whether they fit together until the end.
Estimating honestly
A single number hides what you most need to know. We prefer a range, with a note on what would move it.
- Familiar work gets a narrow range.
- Unfamiliar work, such as an integration nobody has seen yet, gets a wide range and an early experiment to narrow it.
- Assumptions are written down. When one turns out to be false, the plan changes in the open, not by surprise.
A demo every week
Working software on a regular cadence is the best status report. It surfaces misunderstandings while they're cheap to fix and keeps the plan honest. Each demo is followed by a short written note: what shipped, what changed, and what's next.
A sample milestone plan
For a first release, a plan might look like this. The point is that every milestone ends with something you can try.
| Milestone | You can try | Done when |
|---|---|---|
| 1. Thin slice | One real path end to end, rough everywhere else | A user can sign in, do the core task, and see the result |
| 2. Core features | The main workflows, with real data | The top jobs your users do all work, and they're covered by tests |
| 3. Hardening | Edge cases, permissions, and performance | Monitoring, alerts, and a rollback plan are in place |
| 4. Launch | A production deployment | Real users are on it, and your team can run it |
Handling change
Requirements change, and that's fine. What matters is that the change is visible. When a new request arrives mid-project, we write down what it adds, what it displaces, and what it does to the plan. You decide whether to swap it in, add it, or park it. Nothing quietly absorbs the schedule.
Decisions in writing
Keep a short log of significant decisions: what was chosen, what else was considered, and why. When someone joins six months later, or asks why the system works the way it does, the answer exists.
The five phases we use, and what you have at the end of each:
| Phase | What you have at the end |
|---|---|
| Discover | Goals, constraints, and a list of risks |
| Design | An architecture sketch, a prototype where it helps, and a scoped plan with milestones |
| Build | Working software every week, in your repository, with tests |
| Launch | A production deployment, monitoring, and a rollback plan |
| Operate | Support, measurement, and a prioritized list of improvements |
Handover is part of the scope
A project isn't done when the code works. It's done when your team can run it. Plan for documentation, a runbook for common problems, access to every system, and a walkthrough session. We work in your repositories and cloud accounts wherever possible, so there's nothing to move at the end.
