How we scope
a project in
20 minutes

Discovery is usually about the agency, not the project

A two-week discovery sprint produces a requirements document. That document does two things: it tries to capture what needs to be built, and it creates a paper trail that protects the agency when the scope expands. Both are real goals. Neither of them has much to do with whether the project will ship on time.

The hedging happens through the document — padding the estimate against unknowns, writing "out of scope" clauses that cover everything the agency couldn't figure out. The discovery process is, in part, a legal exercise dressed up as a technical one.

Northbound's model doesn't need two weeks of discovery because unknowns are handled differently. The agent surfaces them in the first 24–48 hours of the build — not by guessing, but by reading the actual codebase, the actual schema, the actual brief, and asking the questions a senior developer would ask on day one. So we can scope faster at the front because the safety net is the manifest and the build process, not the discovery document.

What the 20-minute call does instead: it finds out whether you've made the decisions that make a fixed scope possible. If you have, we can price and start. If you haven't, we can tell you exactly which decisions are missing and what to do next.

What the call actually asks

The call runs in three beats. Each question is doing different work. They aren't interchangeable and they're not asked casually — each one is looking for something specific in the answer.

The answers that signal readiness: "A customer opens the app, selects an appointment, pays, and gets a confirmation text within 10 seconds." "A dispatcher assigns a job from the web dashboard and the technician's phone updates in real time." These descriptions are testable. You can build them. You can know when you're done.

The answers that stop the call: "They can manage everything in one place." "It makes things easier for the team." "They'll be able to see what they need." These are product visions, not product definitions. They describe a feeling, not a behavior. A fixed-scope build can't start here — not because the goal is wrong, but because the question of what to build hasn't been answered yet.

Clients who can answer this question have been thinking about their product seriously. "This is not a marketplace — there's one company and one set of users." "This is not a mobile app — web only for v1." "This is not multi-language, multi-currency, or multi-tenant." These answers are not obvious; they require having thought through what you're building and deliberately chosen not to build the other thing.

Clients who can't answer this question are still in exploration mode. They haven't made the cuts. That's a legitimate place to be — but it's the right place for a design sprint or a few sessions of product definition, not a 30-day fixed-scope build. Starting a fixed-scope build with an undefined out-of-scope is how you get to week three with a client who says "I assumed that was included."

Real timelines have consequences: a product launch tied to a conference, a demo for a lead investor, a competitor who is visibly moving, a runway constraint that makes delay genuinely costly. When you ask "what breaks?" and the answer is specific, the timeline is real. We can use that constraint to make trade-off decisions clearly: this feature is in, that one is out, because we have a real ship date.

Aspirational timelines sound like: "We just want to move fast." "The sooner the better." "30 days feels right." These aren't wrong — speed is good — but they don't constrain scope the way a real deadline does. When the timeline is aspirational, the scope conversation is harder because there's no forcing function for the cuts. We can still work with aspirational timelines. We just name them as such and build the scope discipline into the process instead of relying on external pressure.

What "I don't know yet" actually means

Three versions of this answer come up on scope calls. They mean different things.

"I haven't decided yet." The client knows the question but hasn't chosen an answer. This is a design-incomplete project. It can become a fixed-scope build — it just needs a few more decisions made first. The call ends with a short list of open questions, owners for each, and a timeline for when they'll be resolved. Once they're answered, we can lock the manifest and start.

Example: "We haven't decided whether users log in with email or Google." That's a real decision with real implications (OAuth setup, email verification flow, account recovery), but it's answerable. We write it down, the client makes the call, and we incorporate it into the manifest.

"I don't think about it at that level." The client is non-technical and the question is landing as jargon. Not a problem — a reframe usually unlocks it. "When someone forgets their password, should they get a reset email or a text?" Usually answerable in about ten seconds, once the abstraction is gone. This is the most common version and the easiest to work through.

"I'll know it when I see it." This one stops the call. It means the product isn't defined — not in the sense that a decision is pending, but in the sense that the client's vision of the product still lives in their head as a feeling rather than a set of behaviors. This isn't a criticism. It's a common and early-stage place to be. But it's not a fixed-scope build yet.

When this comes up, we say it directly: this project needs product definition before it needs a developer. We recommend a design sprint — four or five sessions of structured product work to define the screens, the flows, and the edge cases — and then a scope call when that's done. The 20 minutes wasn't wasted; it found the blocker before it became a three-week rework conversation.

The manifest: one page, four sections

If the call goes well, the output is a manifest. Not a requirements document. Not a statement of work. Not a 40-page specification that no developer will read past page three.

One page. Four sections. That's it.

The discipline of one page is not a formatting preference. It's a constraint that forces decisions. If you can't describe what ships in a short list, the scope isn't tight enough. Every item on the "Does Not Ship" list is a conversation that won't happen at week three. Every open question is explicitly assigned an owner and a deadline — not left vague with "TBD."

The manifest is also the only document that matters for the build. The agent reads it. The developer references it at checkpoints. If a question comes up mid-build that the manifest doesn't answer, it becomes an open question in the same format, gets resolved with the client, and the build continues. No renegotiation. No change orders. Just a decision, made explicitly, by the right person.

The call is qualification, not discovery

There's a distinction worth naming. Discovery finds out what the project is. Qualification finds out whether the project can be built as a fixed-scope engagement right now. These are different questions with different answers, and conflating them is where most scoping processes go wrong.

A two-week discovery process is trying to do both at once: understand the project well enough to scope it, while also creating a document detailed enough to hold up if the scope expands. The result is a lot of time spent on a document that's already obsolete by the time development starts, because the real questions only surface when the code exists.

The 20-minute call is only doing qualification. It's not trying to understand everything about the project. It's trying to answer one question: has this client made the decisions that make a fixed-scope build possible? If yes, the manifest captures those decisions and the build starts. If not, we say so specifically — not "we need more discovery," but "here are the three decisions you need to make before we can start."

The discovery, such as it is, happens in the first two days of the build. The agent reads the brief, models the domain, and generates the questions the scope call didn't reach. Those questions go to the client immediately, get answered, and get locked into the manifest before the first feature is implemented. That's a better use of 48 hours than a two-week requirements exercise, and it produces a better result — because the questions the agent asks are the ones that actually surface in production, not the ones an account manager guessed at in week one.

The projects that scope easily are the ones that ship

This isn't a coincidence. A project that can be scoped in 20 minutes — with a clear done-state, three explicit non-features, and a real deadline — is a project where the decision-making has already happened. The client knows what they're building. They've made the cuts. They understand the constraints.

Projects that resist scoping usually resist shipping too. Not always. But the correlation is strong enough that we treat it as a signal. When a project can't be scoped in 20 minutes, it's usually not a scoping process problem. It's a product definition problem that will show up again at week two, at week four, and at the delivery call.

The 20-minute scope call is, ultimately, a test of whether the project is ready. Most projects that find Northbound are ready — or are one or two decisions away from being ready. When they're not, we say so, and we say exactly what would make them ready. That's more useful than two weeks of discovery that produces a document everyone signs and no one reads.