How we scope a software project in two weeks

Most software projects that go over budget don’t fail in the build. They fail before it starts, when a vague idea becomes a fixed estimate. Our answer is a short, structured discovery sprint: two weeks to turn an idea into a plan we would bet our reputation on.

Here is what happens during those two weeks, what you get at the end, and the mistakes the process is designed to prevent.

Who should be in the room

Discovery only works when the people who make decisions are available. On your side, that usually means:

• A decision-maker who owns the budget and can say “no” to scope.
• A domain expert who knows how the work is done today, warts and all.
• Someone technical (if you have one) who knows the existing systems and constraints.

On our side, a senior engineer and a product designer lead the sprint, with a delivery lead keeping it on schedule. Expect about four to six hours of your team’s time per week, mostly in short, focused sessions.

Days 1–3: Understand the outcome

We begin with the business, not the backlog. Who is this for? What changes for them if we succeed? How will we measure it?

We run short interviews with stakeholders and, whenever possible, with real users. The goal is a one-page product brief that everyone signs off on: the problem, the audience, the success metrics and, just as importantly, what is explicitly out of scope.

A good brief fits on one page. If it doesn’t, the idea isn’t clear enough yet, and finding that out in week one is far cheaper than in month four.

Days 4–7: Map the system

Next we sketch the system at the level that matters for risk:

• Domains and data. What are the core entities, who owns them, and where do they live today?
• Integrations. Payment providers, identity, legacy systems, third-party APIs. Each one is a risk until proven otherwise.
• Non-functional needs. Expected traffic, availability targets, security and compliance requirements, accessibility.

Where something is genuinely uncertain, we run a technical spike: a few hours of throwaway code to answer one question, such as “Can this carrier API give us real-time updates?” Spikes turn opinions into facts, and they’re the single most effective way we know to de-risk an estimate.

Days 8–10: Shape the first release

With outcomes and risks visible, we work with you to define the smallest release that delivers real value. We prototype the key flows, test them with a handful of users where possible, and plan the order of work so the riskiest pieces are tackled first.

What a good estimate looks like

We never give a single number. Each piece of work gets a range and a confidence level, and every assumption behind it is written down:

Wide ranges are not a weakness. They show you exactly where the risk is, and where a decision from you could narrow it.

What you walk away with

At the end of the sprint you own a set of artefacts that are useful whether or not you continue with us:

1. A product brief with agreed outcomes and scope.
2. An architecture outline and integration map.
3. A clickable prototype of the core journeys.
4. A phased roadmap with estimates, assumptions and risks written down.

Pitfalls the process prevents

• Building the wrong thing well. Interviews and prototypes test the idea before code is written.
• Integration surprises. Spikes expose third-party limits early, not during user acceptance testing.
• Scope creep without trade-offs. A written “out of scope” list makes every addition a conscious decision.
• Estimates nobody believes. Ranges with written assumptions can be challenged, improved and trusted.

Why it works

Two weeks feels like a delay when you are eager to start building. In practice it is the fastest route to launch, because every later decision rests on shared understanding rather than guesswork.

If you are planning a new product or a major rebuild, tell us about it and we will share what a discovery sprint would look like for you.