How We Scope a Project Before Writing a Line of Code

Most bad software projects didn't go wrong in development — they went wrong before anyone wrote a proposal. The scope was vague, the wrong problem got picked, or "custom system" meant something different to the client than it did to the developer. By the time code is being written, those gaps are expensive to fix.

What we actually do first

Before we quote anything, we spend time understanding the process the software is supposed to replace or support — not just the feature list someone emailed us. That usually means:

• Watching (or being walked through) how the current process actually works, spreadsheet or duct-taped tools included
• Identifying who touches the process and what each person actually needs from it, not just who's asking for the project
• Separating "must exist for this to work" from "would be nice eventually" — the second list is real, but it's not what gets built first

Why this saves money, not just time

A scoping conversation that takes two extra days up front routinely saves weeks later. Most scope creep isn't a client changing their mind — it's a requirement that was always there but never got surfaced until someone was staring at a wireframe. Catching that in a conversation costs nothing. Catching it in week six of development costs a rebuild.

The output of scoping isn't a sales document. It's a shared, specific understanding of what "done" looks like — specific enough that both sides would recognize it if they saw it.