How to Scope a 14-Day Software Prototype

We promise clients a working prototype in 14 days, at zero cost, so they can see exactly what they're getting before writing their first cheque. People assume the hard part is the building. It isn't, it's the scoping. A 14-day prototype lives or dies on what you choose to leave out.

This is the framework we use to scope one: pick a single workflow, feed it real data, define success up front, and cut everything that doesn't serve the question you're trying to answer.

First, agree what a prototype is for

A prototype exists to retire risk and create belief, to prove that the core idea works and to let stakeholders feel it, not just read about it. It is explicitly not a v1. It is not production-hardened, not feature-complete, and not the place to litigate edge cases. If you forget this, the scope balloons and the 14 days evaporate.

If everything is in the prototype, nothing is proven. A prototype is a bet on one idea, made visible.

1. Pick one workflow, the spine

Choose the single end-to-end path that carries the most value or the most risk, and build that one all the way through. One user, one journey, start to finish. A travel agent booking a ticket; an adjuster processing a claim; a manager seeing the one dashboard that matters. The temptation is to build a little of everything; resist it. Depth on one workflow beats breadth across ten.

2. Use real, or realistic, data

Nothing exposes a flawed idea faster than real data, and nothing makes a prototype feel real faster either. Get a representative slice of the client's actual data where you can; where you can't, construct realistic data that includes the messy cases. A demo that only works on perfect inputs proves nothing about the real world.

3. Define success before you start

Write down, in advance, what would make this prototype a "yes." It should be concrete and observable:

• A task it must complete, e.g. "process this real claim end to end."
• A number it must hit, e.g. "booking in under 5 minutes," or "extraction accuracy a human agrees with."
• A belief it must create, e.g. "the client can see their workflow in it and wants to keep going."

If you can't state the success criteria, you're not ready to build, you're still in discovery, and that's fine. Naming the criteria is half the work.

4. Cut ruthlessly

Everything that doesn't serve the chosen workflow and its success criteria is out of scope for now. Authentication beyond a stub, admin panels, settings, every secondary workflow, polish on screens no one will judge the idea by, all of it waits. Maintain an explicit "not now" list so cuts are decisions, not omissions, and nobody is surprised.

What the prototype earns you

Done right, two weeks buys more than a demo. It buys a shared, concrete understanding of what's being built, a de-risked path to production, and the evidence a client needs to commit with confidence. Understanding a problem correctly is most of solving it, and nothing forces that understanding like having to make it real in 14 days.

Key takeaways

1. Scope is the hard part, a prototype is defined by what you leave out.
2. Build one workflow end-to-end, not a little of everything.
3. Use real or realistic data, including the messy cases.
4. Write success criteria before you build; keep an explicit "not now" list; show the client every few days.