How We Scope Projects

Most agencies treat scoping like a billable phase. We don’t. If we can’t figure out what to build in a week of conversations, something is wrong with the brief — not with the timeline.

The First Call

We use the first call to understand three things: what the business actually does, where the pain is, and whether software is actually the right solution. Roughly a third of first calls end with us suggesting something other than building — a no-code tool, a different vendor, or a process change. That’s fine. It means the projects we do take on are the right ones.

The Discovery Doc

After the first call we write a Discovery Doc. One page. It covers:

• The problem — in plain language, not requirements-speak
• The proposed solution — what we’d build and why
• What we’re not building — explicit scope exclusions save more arguments than anything else
• Success criteria — how we’ll know it’s working
• Rough timeline and cost — ballpark, not a contract

We share this before writing a single line of spec. If the client disagrees with the problem statement, we need to know before we go further.

Fixed-Scope Sprints

Every project is broken into fixed-scope sprints, typically two weeks. Each sprint has a defined deliverable that a real user can interact with. We don’t deliver “backend work” or “infrastructure setup” as sprint outputs — we deliver working software.

This creates natural checkpoints where the client can change direction without throwing away months of work. In practice, most clients don’t change direction because the Discovery Doc caught the misalignment early.

What We Won’t Do

We don’t sign contracts for work we haven’t scoped. We don’t start building before both sides have agreed on what done looks like. And we don’t scope work we think is wrong for the client just because they’re asking for it.

If you want a months-long discovery phase with 200 pages of requirements, we’re not the right fit. If you want to be using working software in four weeks, call us.