Five questions that turn a vague irritation into something specific enough to build. Work through it honestly and you'll know two things by the end: what the problem is actually costing you, and whether it's worth two weeks of somebody's life.
Every answer stays in this browser until you ask for it
— and what you write in step 01 shapes every question after it.
Not a goal, not a strategy — a specific thing that keeps happening, and a specific person it happens to. Fill in the two blanks; the rest of the worksheet is built out of them.
If you can't name a person doing it, you probably have an ambition rather than a problem. That's fine — but it isn't this.
Most of this cost is already being paid, just in salary rather than invoices. Move the dials to match the thing you just named.
Round down where you're unsure. A number you'd defend out loud is worth more than a flattering one.
Time is the easy part. The real cost is usually somewhere else: the follow-ups that never happen, the errors caught late, the customer who didn't hear back, the person who is quietly done doing this by hand.
If this section is bigger than step 02, the annual figure above is understating the problem — which is common.
Not the software — the day. What happens differently on the first normal Monday after this is solved? What arrives without anyone chasing it?
This is the acceptance test. If the Monday is hard to picture, the problem isn't scoped yet.
Almost everything on a first wish-list can wait. Find the version that works end to end but does one thing — the one that would still change the Monday you just described.
This is the step most projects skip, and it's why they die in scoping. A whole system is a six-month argument. One working piece is a fortnight’s work — and it earns the right to the next piece.
The only question here your other answers can't settle. A fourteen-day build spends its first days building, not waiting — so it doesn't survive a committee.
A no isn't a failure. It means the person who signs off should be on the first call, not shown a proposal afterwards.
Answer the steps above and this fills itself in.
Everything above assembles into a one-page build brief — the numbers, your five answers, and the verdict. It's the same scoping document I'd write on a first call, and it's yours to take to me, to your own team, or to any other developer.
Four out of four and it's worth a call. Three out of four usually is too — bring the answers with you.