The One-Call Scoping Method

Most software projects that go wrong don't fail in the build phase. They fail in the scoping phase — or more precisely, they fail because there was no real scoping phase at all. There was a conversation, maybe a document, and then everyone assumed they were aligned.

We've developed a 30-minute call format that consistently produces real alignment. Here's how it works.

The Problem With Traditional Scoping

Traditional scoping processes have two failure modes. The first is doing too little — a vague brief, a few back-and-forth emails, and then diving into building with a lot of assumptions baked in. The second is doing too much — weeks of requirements documents, wireframes, stakeholder reviews, and planning sessions before a single line of code is written.

Both failure modes are expensive. The first one produces rework. The second one produces documents that are out of date by the time the code is finished.

We want something in between: enough alignment to build confidently, without so much process that you've delayed the feedback loop by three weeks.

The One-Call Format

The call is 30 minutes. We cover five things, in order.

1. The problem in one sentence. We ask the client to describe the problem they're solving in one sentence. Not a paragraph — one sentence. This is harder than it sounds. If they can't do it, that's useful information. It means the problem isn't defined yet, and we need to work on that before we scope anything.

2. The primary user. Who is the person this is built for? Not a persona, not a demographic — a specific, real type of person. A warehouse manager at a mid-sized logistics company. A solo founder who's also their own accountant. Specificity here drives specificity everywhere else.

3. The success criteria. What does success look like at the end of this engagement? This is the question most clients haven't fully answered before getting on the call. We want a concrete answer: "Users can complete a booking without calling us." "The admin can update inventory without opening a spreadsheet." Vague success criteria produce vague deliverables.

4. The explicit non-goals. What are we not building? This is the most underrated part of scoping. Non-goals prevent the scope from expanding incrementally throughout the engagement. They make it safe to say "that's not in scope" without it feeling like a rejection — it was agreed on at the start.

5. The first deliverable. What's the smallest thing we could ship that would let us validate whether we're on the right track? This is the output of the call. Not a full scope — a first milestone. Something real, deployable, and usable.

What Comes Out of the Call

At the end of 30 minutes, we have a one-page document: the problem statement, the primary user, the success criteria, the non-goals, and the first deliverable. That document goes to both sides for a quick review — not a full sign-off process, just a confirmation that both parties read the same thing.

If something is wrong, we fix it in the document. If something is missing, we add it. The whole review usually takes less than an hour.

Then we build.

Why It Works

The one-call format works because it forces decisions that would otherwise get deferred. Most scoping conversations leave ambiguities unresolved because resolving them requires taking a position, and taking a position feels risky. The format makes it clear that we need an answer before we end the call.

It also keeps the scope small enough to be real. A 30-minute call can only produce so much output. That constraint is a feature — it stops the scope from becoming a roadmap for the next six months when what you actually need is something you can ship next week.

The best scoping is the kind that makes the first week of building feel obvious. For what that first week actually looks like in practice, see What Actually Happens in the First Week of a Software Project.