← Back to all posts

You have an idea for a software product. Maybe it has been rattling around in your head for months. You have seen the gap in the market, you know the pain point, and you are ready to build. The question is: what do you build first?

This is where most first-time SaaS founders go wrong. They try to build the whole vision on day one. They end up six months and $80,000 into a product that has never been used by a single paying customer. The features are polished, the onboarding is slick, and nobody wants it.

An MVP—minimum viable product—is not about building less. It is about building the right things first and proving that people will pay for them before you invest in everything else.

The Four Things Every SaaS MVP Needs

1. Authentication (The Front Door)

Users need to sign up, log in, and have their own account. This is table stakes and it is not negotiable. But here is the key: keep it simple.

What to build:

What to skip for now:

Use a battle-tested auth library or service. Do not build authentication from scratch. Services like Auth.js, Clerk, or Supabase Auth handle the security-critical parts so you can focus on your actual product.

2. The Core Value Proposition (The Reason People Pay)

This is the one thing your product does that makes someone pull out their credit card. Not three things. Not five things. One thing.

If you are building a project management tool, the core value is not Gantt charts, time tracking, resource allocation, and reporting. The core value is one of those things. Figure out which one your target customer cares about most and build only that.

The litmus test: can you explain what your MVP does in one sentence? If the sentence has the word "and" in it more than once, you are building too much.

Examples of good MVP scope:

Examples of MVP scope that is too broad:

Build the core feature well. Make it reliable, make it fast, and make it solve the problem better than the spreadsheet your customer is currently using. That is your entire job at the MVP stage.

3. Billing (The Revenue Engine)

This is the one that first-time founders most often postpone, and it is a mistake. If your MVP does not accept payments, it is a demo, not a product. You learn nothing about whether people will pay until you actually ask them to.

What to build:

What to skip:

Start with two tiers: a free tier with meaningful limitations and a paid tier that removes those limitations. That is it. You can always add pricing complexity later. Right now, you need to answer one question: will anyone pay for this?

4. Basic Admin (Your Control Panel)

You, as the founder and operator, need a way to see what is happening in your product. This does not need to be fancy, but it needs to exist.

What to build:

What to skip:

In the early days, you can check Stripe for revenue, check your database for user counts, and talk directly to users for feedback. You do not need a dashboard for 20 customers. You need a dashboard for 2,000. Get to 20 first.

What to Explicitly Skip

Now the hard part. Here are the features that feel important but will slow you down without teaching you anything:

Mobile app

Build a responsive web app. It works on phones already. A native iOS or Android app doubles your development time and maintenance burden for a marginal improvement in user experience. If mobile is critical to your product, use a progressive web app (PWA) approach. Build native apps after you have validated the product and have revenue to justify the investment.

Social features

Comments, activity feeds, user profiles, notifications, sharing—these are features that make sense at scale. With 15 users, there is no one to be social with. Social features are engagement multipliers, and you cannot multiply zero.

Analytics dashboards

Your users do not need charts and graphs in the MVP. They need the core tool to work. Analytics are a retention feature, not an acquisition feature. Nobody signs up for a product because of its reporting. They sign up because of the core value, and they stay because of the reporting. Build it after they sign up.

Fancy onboarding

Product tours, interactive walkthroughs, video tutorials, drip email sequences—all of these are optimization tools. They optimize a conversion funnel that does not exist yet. If your product requires a 10-step onboarding wizard to make sense, the product is too complicated for an MVP, not the onboarding.

For your MVP, the onboarding should be: sign up, see the product, start using it. If that does not work, you have a product problem, not an onboarding problem.

Integrations

Zapier, Slack, email integrations, API access—all valuable, all later. The only integration in your MVP should be Stripe for billing. Every other integration is a nice-to-have that you will build when customers ask for it. And they will ask. That is a good problem to have.

Perfection

The MVP does not need pixel-perfect design. It needs to be clean, functional, and professional—but it does not need custom illustrations, animations, or a design system. Use a component library like Tailwind or Shadcn, pick a clean color scheme, and move on. You can hire a designer after you have revenue.

The 6-8 Week Timeline

A well-scoped SaaS MVP should take 6-8 weeks to build. Here is how that time typically breaks down:

If your scope cannot fit into this timeline, you are building too much. Go back to the core value proposition and cut harder. The goal is not to build a complete product. The goal is to build enough product to learn whether people want what you are making.

The Feature Prioritization Framework: Must / Should / Could

The three-tier framework is the most practical tool for scoping an MVP without endless debate over the feature list. Every proposed feature gets sorted into one of three buckets before development begins:

Must: The product cannot function without this. If it is missing, users cannot complete the core workflow. Authentication and core value proposition both live here. So does billing—because without billing, you have no product, you have a prototype.

Should: This makes the product significantly better, but users can work around its absence. Notifications that remind users to come back. Search that helps users find records faster. A settings page that lets users configure basic preferences. These are post-launch priorities—build them in the second sprint.

Could: Nice to have, but the product serves its purpose without them. Integrations with third-party tools. Dark mode. Advanced analytics. White-label options. These go on a public roadmap. They are promises to future customers, not obligations to current ones.

The discipline is in rejecting everything that is not clearly a “Must.” The natural human pull is to move “Should” items into “Must” because they feel important. They are not wrong to want—they are just wrong for week one.

The Real Cost of Building Too Much

Over-scoped MVPs are not just slow. They cost significantly more and teach you less.

Consider a founder who spends six months and $90,000 building a full-featured project management tool before getting a single paying user. They have beautiful Gantt charts, time tracking, resource allocation, client portals, and a mobile app. When they launch and nobody converts, they do not know which feature they are missing. They do not know if the problem is the pricing, the onboarding, the positioning, or the core value proposition itself. They have too many variables.

Now consider a founder who spends eight weeks and $12,000 building only the core feature—say, a one-click proposal tool for freelancers. They launch to 20 users. Ten of them pay. The other ten give feedback. The feedback says “I need to track whether the client opened the proposal.” Now the founder knows exactly what to build next. They spend another four weeks and $4,000 adding open-tracking. Another round of feedback. Iterate.

The first founder spent $90,000 to learn nothing. The second spent $16,000 to learn everything that matters.

What Happens After the MVP

The MVP is not the end of building—it is the beginning of building the right things. Here is what the post-launch sprint cycle typically looks like for a well-scoped MVP:

The pattern is: build the minimum, learn from real usage, build what the usage tells you to build. Repeat until you have a product with repeatable retention. That is when you start adding the features you wanted to build on day one.

Choosing Your Stack to Match MVP Speed

Your technology choices in the MVP phase have a disproportionate impact on how fast you can iterate. Some choices that look sophisticated slow you down significantly at small scale.

For most SaaS MVPs in the $0–$10k ARR phase, the pragmatic stack is:

This stack lets a solo developer or small team go from zero to production in 6–8 weeks without building any infrastructure from scratch. Every component is battle-tested, well-documented, and can handle your scale until you have significant revenue to invest in alternatives.

The Question That Matters

For every feature on your list, ask: “Will this feature help me learn whether my product has a market?” If the answer is no, it goes on the post-MVP list. Authentication helps you learn (people have to sign up). Billing helps you learn (people have to pay). A dark mode toggle does not help you learn anything.

The MVP is not the product. It is the experiment. Build just enough to run the experiment, learn from the results, and then build the product your customers actually want—not the one you imagined in isolation.

Have a SaaS idea and need help scoping the MVP? The studio specializes in getting products from idea to launch in 6–8 weeks.

Let’s Scope Your MVP

Ship fast. Learn fast. Build what matters. Skip everything else until your customers tell you they need it.

If you are building your own MVP and want a head start on the skills side, Septim Drills ($29) is 25 production Claude Code skills—PR review, test gap checks, refactor prompts, launch post generation. Drop them into your workflow and the parts of development that tend to slow founders down get handled consistently on every commit.