Scope it properly before you start

Hello there,

Let me tell you where projects actually go wrong. It's almost never the coding. It's the fuzzy patch at the very start, where everyone nodded along but nobody wrote down what they were nodding at.

Scope is just the answer to one question: what are we building, and what are we not? The second half matters as much as the first.

The cost of a vague start

When scope is loose, every decision gets made twice — once badly, in a rush, and once again after someone realises. That's where budgets quietly disappear.

• "I assumed that was included" turns into a hard conversation
• Small extras pile up until the timeline breaks
• Nobody can say if you're finished, so you never quite are

What a clear scope looks like

A good scope isn't a giant document. It's a short, honest agreement. When I set one up with a client, I want to see:

1. The outcome — what's different for the business once this ships
2. The boundaries — the tempting things we're deliberately leaving out for now
3. The assumptions — written down, so we notice fast when one turns out wrong

Half an hour spent agreeing what's out of scope saves a fortnight of "while we're at it".

The trick is naming the things you're not doing. That's what stops a tidy project sprawling into a shapeless one.

None of this needs to be heavy. It needs to be written, shared and agreed before anyone opens a code editor. Say it out loud, put it on one page, and let everyone see the same picture.

If you're staring at a project that feels bigger than it should, book advisory time and we'll cut it down to something you can actually finish.