How I approach building a SaaS MVP

The useful first version of a product is usually smaller than people expect, and more specific.

When someone says they want a SaaS MVP, the request often arrives as a list of features: accounts, dashboards, billing, notifications, an admin panel, maybe AI. That list can be built. It is rarely the right first version.

I start somewhere else: what work is happening today, and where does it break?

Understand the workflow before the product

On a travel operations product I worked on, the problem was not “we need a travel app.” It was that itineraries, bookings, tours, activities, and customer communication lived in different places. The first version had to pull those workflows into one product people could actually operate — not demonstrate a marketplace, a social feed, and a recommendation engine at the same time.

That is the Discover step. The goal is not to start coding. It is to understand the people who will use the software, the current process, and what “working” would look like in a normal week.

If that conversation is skipped, the MVP becomes a pile of screens searching for a job.

Define a first version that can be used

After the problem is clear, I look for the smallest set of flows that would make the product worth opening again tomorrow:

• Who is the first user, really?
• What do they do in the first five minutes?
• What data has to exist for the software to be useful?
• What can wait until someone has used the first version?

That last question matters more than people like to admit. Architecture should leave room to grow — billing, extra roles, more modules — but those are not proof that v1 exists. They are bets on v2.

For a travel operations product, that meant focusing on the operational core: the pieces of work that were already being coordinated by hand. Integrations, extra roles, and polish can follow once that core is real.

Choose technology for the product you are actually building

I do not start with a default agency stack. That travel operations product used Next.js, React, TypeScript, Node.js, and PostgreSQL because those fit a full-stack product that needs a durable data model and a web interface operators can live in.

A different product might need less. A workflow that only has to capture and organize incoming leads does not need the same shape as a multi-tenant SaaS platform. The stack should follow the product, the expected usage, and what will still be maintainable after launch.

Ship something people can use, then learn

An MVP that nobody can use is a specification with a UI. I would rather put a narrower product in front of real use — even internally — than keep adding features in private.

That is also why I do not treat “MVP” as a personality. Some projects already have a product and need a focused improvement. Some need custom software around an existing business process. The same rule still holds: understand the problem, define a useful first slice, build that, then learn.

If you are trying to turn an idea into a first version, I wrote more about that path on the process and MVP pages. If the idea is already specific enough to discuss, start a project.