How I Scope a Software Project (and Why Fixed Quotes Are Possible)

The horror stories are real: projects that doubled in cost, agencies that vanished after the advance, software delivered eighteen months late that nobody could use. Almost every one of these stories begins the same way — with a vague scope agreed too quickly by two parties imagining different products.

Why vague scopes fail

'A website with a student portal' means fifty different products depending on unstated assumptions. Does the portal include payments? Test analytics? Parent logins? Each assumption gap becomes a mid-project negotiation, and mid-project negotiations are where budgets and relationships die.

What proper discovery looks like

Before quoting anything, I run a structured discovery: who uses the system, what they do in it screen by screen, what data flows in and out, and what existing systems it must talk to. This produces a written scope where both of us can point at the same document and see the same product.

Discovery is also where I'll tell you if part of what you want shouldn't be built — because a tool already exists, or because a simpler version proves the idea for a fifth of the cost.

Slices, not phases

I structure builds as usable slices rather than abstract phases. Instead of 'backend (month 1), frontend (month 2)' — which means nothing works until everything works — each slice is a complete usable capability: enquiries flow end to end, then payments, then reporting. You see working software within weeks, and if priorities change, we reorder slices instead of renegotiating a monolith.

What this means for you as a buyer

Whoever you hire — me or anyone else — insist on these three things: a written scope that names every screen and workflow, delivery in working slices you can actually use, and clarity on who owns the code and infrastructure. Any professional will welcome these questions. The ones who dodge them are telling you something important.