# Your SaaS MVP needs one complete workflow

By Amminadab Elias | 2026-09-05

Canonical: https://amminadab.me/blog/saas-mvp-one-workflow

A product idea can sound small until you list the screens it needs. There is a dashboard, an admin panel, a settings page, a billing page, and probably an AI feature someone wants to try. Soon, the first release has enough work for several releases.

When I scope a SaaS application, I start with a more useful question: what should one person be able to finish when they use it?

That question changes the conversation. A ticketing product needs someone to find an event, make a booking, and receive a usable ticket. A travel platform needs a request to reach an agent and turn into an offer the traveller can understand. The screens matter because they support that journey.

## Choose the first useful outcome

Write down the person, their task, and the result they need. Keep the sentence plain enough that someone outside the development team can understand it.

For an early event platform, an example might be: an organiser can publish an event, share its booking page, and see which bookings were completed. That is specific enough to discuss. “Build an event ecosystem” leaves too much room for everyone to imagine a different product.

GOV.UK's guidance on [writing user stories](https://www.gov.uk/service-manual/agile-delivery/writing-user-stories) connects a feature to the person using it and the reason they need it. I use that connection to decide which work belongs in the first release.

The outcome also gives a demo a purpose. At the end of a milestone, we should be able to complete a task with realistic information. A collection of finished screens is harder to evaluate if the information does not move between them yet.

## Build through the whole application early

I prefer the first milestone to cross the interface, backend, and database. It can be narrow. One kind of account, one form, one saved record, and one place to review that record are enough to reveal useful problems.

Consider an illustrative event request flow. A customer submits the request. The server checks it, saves it, and gives it a status. An organiser can open it later and decide what to do. That small journey forces us to answer questions a static mockup can hide. Who owns the request? Can the customer edit it? What should happen if the connection drops after saving?

My work on TripBooka connects traveller requests, agent proposals, and application data. Those connections are a useful reference when thinking about scope. A proposal screen depends on what a traveller submitted and what the agent can access. Designing those parts in isolation would leave the hard decisions until integration.

This is also why I want real sample content early. Long names, incomplete records, and an account with no activity tell us more than a dashboard filled with perfectly balanced placeholder cards.

## Make the cuts visible

A smaller first release still needs a clear boundary. I keep three short lists: what must work, what can be handled manually for now, and what is deliberately deferred.

For our example event product, the first list might include publishing an event, booking a place, and viewing confirmed bookings. A custom report could be handled manually if the team understands the work involved. A complex promotion engine might wait until the basic booking flow has been used.

These are scope decisions to agree with the people operating the product. If a manual step is essential, name who will do it and how often. Otherwise, a feature removed from the development plan quietly becomes an unexpected job for someone else.

Early work should also test the riskiest assumption. If the product depends on access to an external system, confirm that access before polishing every screen. GOV.UK's [alpha-phase guidance](https://www.gov.uk/service-manual/agile-delivery/how-the-alpha-phase-works) describes using early work to investigate risky assumptions. The same habit helps a small commercial product avoid building around an integration it cannot use.

## Small scope still needs complete behaviour

I would cut an extra dashboard before cutting permission checks or a clear recovery path. A small product will still encounter invalid input, interrupted requests, and users who press a button twice.

For each important action, I want a few concrete answers:

- What does the user see while the request is running?
- What happens if it fails before anything is saved?
- What happens if it succeeds but the response never reaches the browser?
- Can the user safely try again?
- How does a teammate find and help with a stuck record?

For a booking flow, “something went wrong” is not much help if a payment might already have completed. The product needs a way to check the actual state and explain the next step. The exact implementation depends on the payment provider and the workflow, but the question belongs in the scope discussion.

## Agree on what ready means

Before development starts, I like to turn the main outcome into a short acceptance list. Use actions and observable results: an organiser can publish an event; a customer can complete the agreed booking flow; the organiser sees the resulting record; another organiser cannot access it.

Then add a handoff list. The code should have setup instructions, a description of required configuration, and a clear place to find the important workflows. The team should know what is included in the release and what still needs attention.

For the first real users, choose a few things worth learning. Where do they stop? Which task needs help? What information do they expect to find? Collect only the information the team has a reason to use, and avoid putting sensitive customer data into casual debug logs.

A useful first release gives you something concrete to improve. You can watch someone complete the task, learn where it becomes difficult, and make the next decision from that evidence.

If you are planning an MVP, send a developer the first task you want a customer to finish, a sample of the information involved, and the constraints you already know. That is a much stronger starting point than a long feature list with no clear order.