What a Discovery Sprint is, and when you need one

What a Discovery Sprint is

A Discovery Sprint is a short project with a fixed scope, a fixed quote and a fixed end date, usually two to three weeks. It covers the discovery phase of a product: who it is for, what it must do first, and how it should be built. It ends with a working MVP, software you can open, click through and put in front of real people. Not a slide deck, and not a document describing an app that does not exist yet.

If you continue to the full build with us, the sprint fee is credited to the build. The work is never thrown away; it becomes the first stage of the product.

Why not go straight to the full build?

A complete SaaS product, on web and mobile, takes us eight to fourteen weeks. A fixed quote for something that size is only as good as the scope behind it. When the idea is new, that scope is a set of guesses: which feature matters most, how users will move through the product, which integrations are needed, what the data looks like.

Building on guesses is how projects run late. A wrong assumption found in week ten costs far more to fix than one found in week two. MVP development in a short sprint moves the expensive questions to the start, where they are cheap to answer.

What happens during the sprint

The steps are the same each time, adapted to the product:

Goals and users: who the product is for, the one job it must do well, and how you will judge the first version.
Scope in screens: what a user can do, screen by screen, and a written list of what is left out.
Technical choices: the stack, hosting, accounts and roles, and the integrations that matter first, such as payments, email or WhatsApp.
A working MVP: the core flow built for real, on real infrastructure, ready to share with early users.
A build plan: stages, dates and a fixed quote for the full product, based on what the sprint taught us.

When you need one

A Discovery Sprint makes sense when the product is new, when you are not yet sure which features come first, or when you need something real to show partners, investors or first customers. It also helps when an internal tool must replace spreadsheets and nobody has written down how the work actually flows.

You probably do not need one when the scope is already clear and documented, for example a rebuild of an existing system with known screens, or a well-defined client portal. In that case we scope the build directly.

The goal of discovery is not a document about your product. It is a first version of it that you can use.

What you have at the end

After two to three weeks you have a working MVP, a written scope for the full product, and a plan with stages and dates. On full payment, the code and the accounts it runs on are yours. You also have something more useful than a plan: first reactions from real users to software they can touch.

From there you decide. Continue to the full build with the sprint fee credited, take the plan elsewhere, or pause. Each is a reasonable outcome, and you choose with evidence rather than hope.

Four questions to ask before you start

Whoever runs your discovery phase, ask the same things: what exactly will exist at the end, who owns it, how the price of the full build will be set, and what happens to the sprint fee if you continue. Clear answers to those four questions tell you most of what you need to know about how the rest of the project will go.

How we work at Qafza

Our Discovery Sprint lasts two to three weeks, has a fixed quote and ends with a working MVP. You follow it in a private client space, with milestones, files and approvals in one place and two revision rounds per stage. If you continue, the fee is credited to the full build, delivered in milestones. We promise the scope, the dates and the quality. Once real users arrive, we measure sign-ups and usage with you.

A working MVP in 2–3 weeks, not slides.Book a 30-minute scope call