A SaaS MVP: what should you build first to avoid an unfocused budget?

The product has no users yet, but its backlog already includes billing, reporting, chat, mobile apps and several industry-specific versions. Technology is not the missing ingredient. The unclear part is which experience must work for someone to evaluate the offer. A usable MVP focuses on one hypothesis and one complete journey without treating scope reduction as permission to ignore access control or persistence.

Describe the hypothesis before the features

Identify a user who can complete a currently difficult task and explain why they would use the product again. In a hypothetical tool for small service businesses, the core journey might record a request, assign its state and retrieve the next follow-up. A dashboard full of charts may not test that hypothesis at all.

Define what you will observe: task completion, misunderstandings and reasons to continue or stop using the tool. These are research questions, not predictions of revenue or retention. If the target user is still undefined, interviews and a prototype may be more appropriate than complex infrastructure.

Maintain three scope lists

Billing can be deferred if the test does not involve real sales. Tenant separation cannot be skipped when people from different organisations already share an application. Each deferral needs an understood consequence rather than a vague “phase two” label.

Distinguish a prototype from a usable release

A screen prototype can test understanding. A usable release must handle saving, return visits, errors and authorisation. Clicking through a demonstration does not prove that data is processed correctly. Make simulated behaviour explicit so participants do not validate expectations the implementation cannot meet.

Test the task with incomplete data, an unauthorised user and an interruption. Agree recovery and issue-reporting procedures. A modest but clearly bounded foundation makes later changes easier to assess than a collection of disconnected features.

Commission a hypothesis with acceptance criteria

My SaaS and MVP service can help narrow the journey, design access and data, and build a first usable version. Integrations, billing and operations follow demonstrated requirements and agreed scope. For a technology decision grounded in requirements, read how to choose a stack.

Bring the expected user, a complete task and what needs to be learned. That brief creates a more useful starting point than a package measured only in screens.