Most custom software projects don't fail in the build. They fail in the two weeks before it, when nobody wrote down what "done" means.
Scoping is the part of our process we refuse to skip, even for small automations. Here's what it actually looks like.
Start with the workflow, not the feature list
We don't open the first call asking what you want built. We ask how the work moves today: who touches it, where it stalls, what gets re-typed between systems, and what happens when someone is on holiday. The software we end up proposing is usually smaller than the feature list you arrived with — because half of a wish list tends to dissolve once the real bottleneck is on the table.
Name the smallest version worth shipping
Every scope we write has a line in it: the smallest version of this system that would still be worth paying for. Not a prototype — a working slice that handles the core path end to end. Everything else is staged behind it. This is what keeps a six-week build from quietly becoming a six-month one.
Write down what we're not building
The scope document lists exclusions as explicitly as inclusions. "No mobile app in phase one. No two-way sync with the legacy CRM — read-only import instead." Exclusions are where budget disputes go to die, so we put them in writing before anyone commits to anything.
Fixed proposal, phased delivery
You get a proposal with phases, durations, and a number — before any commitment. Builds run in weekly, shippable increments on a staging environment you can click through from the first week. If the scope was honest, there are no surprises. If something genuinely changes mid-build, the scope changes in writing, with a number attached.
Why we work this way
Because we're the ones who have to live with the codebase, and you're the one who has to live with the invoice. A sharp scope protects both. If you bring us a project and the honest answer after scoping is "you don't need custom software for this" — we'll say that too. It has happened more than once.