Before you commission a SaaS MVP, answer these seven questions

1. Who needs this enough to change how they work?

A feature list tells a developer what to build. It rarely explains what the first customer needs to get done. Before requesting an estimate, describe that customer, the problem they face and the workaround they use today. A spreadsheet, a shared inbox or three disconnected tools may be your real competition.

Choose a specific starting audience. Software for every small business is difficult to scope. Software that helps a property manager collect maintenance requests gives a team a clearer problem to investigate. Bring notes from actual conversations, including objections. Interest in an idea is useful; evidence of an inconvenient recurring task is more useful.

2. What must the first customer finish?

Describe one complete journey, from the moment someone arrives to the result they came for. For a scheduling product, that might mean creating availability, sharing a booking link, receiving a reservation and changing it later. The cancellation path belongs in the discussion too.

Split the scope into what makes that journey usable and what can wait. An attractive dashboard does not compensate for a booking that disappears. Write acceptance criteria in ordinary language so everyone can recognize when a feature works.

• Required at launch: the customer can complete the core task and recover from common mistakes.
• Later: improvements that add convenience without blocking that task.
• Unknown: assumptions that need research or a technical experiment.

3. What should you learn before writing the application?

A prototype can reveal whether people understand the workflow before the underlying software exists. Ask potential users to complete a task, then watch where they hesitate. Avoid explaining every screen while they use it; you need to discover what the interface communicates on its own.

Google's Design Sprint guidance includes user feedback, stakeholder review and technical feasibility in validation. Apply that distinction to your project. A usable screen does not prove an external system will provide the data it needs. Test that integration separately.

4. Who can see and change the data?

List the account types before drawing the administration screens. An owner, employee and customer may need different permissions. Decide who can invite colleagues, approve changes, export records and delete an account. If several businesses use the product, specify how their records remain separate.

Include these decisions in the scope. They affect the data model and the tests, not just the settings page. Use realistic sample records so the team can discuss the awkward cases without sharing private customer information.

5. Which outside services does launch depend on?

Name the payment provider, email service, identity system and business tools the product must connect to. Check account access, available documentation, usage limits and test environments early. Also decide what users should see when one of those services is unavailable. A dependency list is more useful than a vague requirement to integrate everything.

6. What does ready to launch mean?

Agree the supported devices, accessibility checks and performance expectations alongside the feature scope. A performance budget gives the team measurable limits to use when choosing features and visual effects. Test the important journeys on the devices your customers actually use, including a slow connection and an interrupted session.

7. Who looks after the product after release?

Confirm who owns the source code, hosting accounts and service subscriptions. Assign responsibility for monitoring, backups, updates and support. Firebase's launch checklist is one useful example of the operational details involved: access rules, separate environments, crash reporting and cost monitoring. Its budget alerts notify you about spending; they do not cap it.

Bring your customer notes, workflow and open questions to Resoltives. We can help turn them into a focused SaaS brief, a practical first release and a clear plan for what comes next.