Turn the idea into a testable assumption
Describe one user, a recurring problem and an expected result. For example, a manager receives requests by email and wants to assign them without losing their history. The assumption is that this journey deserves adoption, not that ten features will look convincing in a demo.
Decide what to observe before testing: does the person finish the task, where do they hesitate, do they return and do they ask to continue? Stated intention and repeated use are different signals.
Test the biggest uncertainty first
If the risk is whether people value the journey, a mockup or assisted test may be enough initially. If it is an essential integration, check that connection early. Avoid committing the whole budget to an interface before the decisive part is feasible.
GOV.UK’s alpha guidance recommends testing the riskiest assumptions. We use that validation principle here; an exploratory prototype and an operational product remain different deliverables.
Choose what belongs in the MVP
An MVP needs a coherent journey, rather than a collection of unfinished screens. List what the user must accomplish and what the team can handle manually during a pilot. Make limitations clear to testers.
- One main task and the information needed to complete it.
- Appropriate access, validated inputs and understandable errors.
- A way to receive feedback and investigate incidents.
- An explicit list of deferred features without implied commitments.
Avoid complexity before it is needed
A first version needs clear code boundaries, backups and understandable operations. It does not automatically need an independent service for every feature. Technical choices should address observed constraints.
Martin Fowler describes the cost of separating microservices while product boundaries are uncertain. That observation encourages teams to justify complexity; it does not prohibit a distributed design when requirements call for one.
Budget for use after delivery
Tools, hosting and operating work continue beyond the build. Decide who handles feedback, what data is retained and how the next decisions will be made. Every tester request should not automatically become development work.
The Okys MVP / SaaS sprint targets a first testable journey in 14 days at €5,000 for approved scope. You pay half at launch and the balance on delivery; you own the code. It promises neither every SaaS feature, sales, nor already-validated scaling. Further work is scoped after reviewing the need.
Before you decide
- Name one initial user and their priority task.
- Identify the assumption that could invalidate the project.
- Separate the essential journey from deferred features.
- Plan operations, feedback and criteria for the next decision.
Common questions
Does the first MVP need payment integration?
Only if collecting payment is part of what you need to test. An assisted pilot can sometimes validate use another way. Billing and access requirements still need scoping.
Is one sprint enough to launch the entire SaaS?
Not necessarily. The sprint targets a first journey with defined scope. Additional roles, integrations, operating requirements and features depend on the project.