Scoping a Custom Application Project

Scoping is the most undervalued phase of custom development. Teams want to start coding immediately. That impulse costs them. The teams that spend time on scoping finish faster and waste less money.

What Happens When You Skip Scoping

I've seen projects where the CEO was excited about an idea, the team started coding immediately, and six months later they had built the wrong thing. The CEO wanted feature X, the team thought the priority was Y, and nobody wrote down what they were supposed to build. The result: months of rework, team frustration, and missed deadlines.

I've seen teams estimate a project at 3 months, start coding, and discover at month 2 that they didn't understand the requirements. Requirements they thought were simple turned out to have 10 edge cases nobody mentioned. A 3-month project became a 7-month slog.

I've seen architectural decisions made on day 2 of coding that locked the team into constraints that made subsequent features 10x harder. A decision that would have taken 30 minutes to reconsider on day 1 cost weeks to rework on month 4.

Scoping prevents these failures. Not always—some unknowns only emerge during building. But the ones that can be prevented should be.

What Good Scoping Produces

Clear requirements. Everyone agrees on what will be built. Not just the developer and the CEO, but all stakeholders who will use the system.

Realistic estimates. The team has looked at the requirements and broken them into tasks. They have a shared estimate of how long this will take, with confidence intervals. They've built in buffers.

A shared mental model. When a developer asks "should we do X or Y?" there's a document to refer to. Decisions can be made without reconvening every stakeholder.

Identified risks. The team has thought through potential problems. They know what will be hard. They can plan for it.

A scope document. What's in. What's out. What decisions have been made. This becomes the reference for the rest of the project.

How Long Does Scoping Take?

For a simple project, 1-2 weeks. For a moderate project, 2-4 weeks. For a complex project, 4-8 weeks. This is before any code is written. It feels like overhead. It's not. It's insurance against building the wrong thing.

The common objection: "We need to move fast. We can't afford to spend a month scoping." The counter: if you skip scoping, you'll spend an extra month recoding mid-project. Scoping moves the pain forward. You do the hard thinking when changes are cheap (on paper).

Who Participates in Scoping

The product owner or CEO. They have the vision and can make decisions about what matters.

A senior developer or architect. They know what's technically feasible and what will be hard. They ask the questions that prevent naive requirements.

A UX designer (or someone who thinks about user experience). They can catch requirements that don't make sense from a user perspective.

The people who will use the system. Internal tools need input from the team that will use them. Customer applications need user research or customer interviews.

Scoping doesn't require a huge team. A product manager, a senior developer, and one user representative can define scope well.

The Scoping Process (High Level)

1. Gather requirements from stakeholders and users
2. Write user stories and acceptance criteria
3. Design wireframes or mockups
4. Define scope (what's in V1, what's V2+)
5. Do technical discovery (architecture, integrations, risks)
6. Estimate effort
7. Create a scope document and get sign-off

The rest of this section walks through each step.

The Common Mistakes

Skipping user research and talking only to the person who commissioned the project. They have one perspective. Users have a different perspective. Often contradictory.

Writing requirements that are really solutions. "We need a dashboard" is not a requirement. "We need to see real-time sales data and compare it to yesterday" is. A requirement is a need. A solution is how you address it.

Ignoring edge cases. "What happens if two people try to update the same record at the same time?" "What happens if the payment API is down?" "What happens if a user has 100,000 data points?" Edge cases that aren't addressed in scoping become crises during development.

Underestimating how long things take. A senior developer who estimates a project usually gets it roughly right. A non-technical person estimating usually gets it 50% wrong (half the time too optimistic, half the time too pessimistic). Get a developer involved in estimation.

Not freezing scope. Scope needs to be frozen before development starts, or it grows infinitely. Changes after the freeze are explicitly assessed for impact and added to the timeline.

Read through this section and you'll avoid these mistakes.