SaaS MVP: What to Build First and What to Skip

4 features. That's what Pushary launched with. Campaigns, flows, analytics, and billing. We cut 11 features from the original scope. The product shipped in 30 days, acquired paying users in week 2, and the features we cut? Three of them never got built because users didn't need them.

Most SaaS MVPs fail not because they ship too little, but because they ship too much. Every extra feature adds development time, increases bug surface, delays launch, and dilutes the product's value proposition. We've built enough MVPs to know that the hardest part isn't writing code. It's deciding what code not to write.

Key Takeaways > - Ship with 3-5 core features. If you can't explain why a feature is essential for the first paying user, cut it. > - Build billing from day one. Free products attract free users. You need paying users to validate a business. > - Skip admin panels, analytics dashboards, and notification preferences in v1. All of them feel essential. None of them are.

The Framework: Will the First Paying User Need This?

We use a single question to evaluate every feature in an MVP scope: will the first paying user need this to get value from the product?

Not "would users like this?" Not "do competitors have this?" Not "will we eventually need this?" The question is specific and binary. If the answer is no, it's out of v1.

When we scoped Pushary, the original feature list had 15 items. We ran each through this filter:

- Campaign creation: Yes. Can't send push notifications without it. In. - Automation flows: Yes. This is the core differentiator. In. - Analytics dashboard: Yes. Users need to see if their notifications worked. In. - Billing: Yes. We need to charge money to validate the business. In. - Team management: No. The first user is a solo founder or small marketing team. Out. - A/B testing: No. Users need to send one successful campaign before they test variations. Out. - Custom templates: No. We provide default templates. Customization comes when users hit the defaults' limits. Out. - API access: No. The first users will use the dashboard, not the API. Out. - White-labeling: No. Nobody white-labels a product they just discovered. Out.

We went from 15 features to 4. Development time went from an estimated 4 months to 30 days. The product still solved the core problem: sending targeted push notifications to users.

What to Build First (The Non-Negotiables)

Every SaaS MVP needs exactly five things. Not features - infrastructure.

1. Authentication that works

Email/password signup, password reset, and session management. That's it. No social login, no SSO, no magic links in v1. Social login adds 2-3 days per provider and complicates your auth flow. Magic links require email deliverability optimization that you don't want to debug during week 1.

Use an auth provider (Clerk, Auth0, Supabase Auth) instead of building your own. Custom auth is the highest-risk, lowest-reward code in an MVP.

2. The one thing your product does

Every SaaS has one core action. Pushary sends push notifications. Morta manages real estate contacts and deals. Automaticall answers phone calls with AI. If you can't describe your product's core action in one sentence, your scope is too broad.

Build that one action end-to-end. From the user clicking a button to the result being delivered. Make it work reliably. Polish the UX of this one flow more than anything else. The first impression of your product is this action, not your settings page.

3. Billing from day one

This is our most controversial recommendation. Most founders want to launch free, build an audience, then add billing later. We think that's backwards.

Free users behave differently than paying users. Free users request features they'd never pay for. Free users don't report bugs urgently because they have no investment. Free user feedback is interesting but unreliable for building a business.

Stripe Checkout takes one day to integrate. Usage-based billing takes two weeks. For an MVP, use simple flat-rate pricing with Stripe Checkout. You can always add tiers and usage metering later.

Pushary charged from day one. The users who paid in week 2 gave us better feedback in one conversation than a hypothetical free user base of 500 would have.

4. Enough analytics to know what's happening

Not a full analytics dashboard. Just enough to answer: are users doing the core action? How often? Where do they drop off?

For an MVP, this means event tracking (Mixpanel, PostHog, or even just server-side logging) and a simple activity view in the product. Pushary's v1 analytics showed campaign send count, delivery rate, and click rate. Three numbers. Enough to know if the product worked.

5. A way for users to get help

A support email address. That's it. Not a help center, not a chatbot, not an in-app knowledge base. An email address and a commitment to reply within 24 hours. Your early users will email you problems that reveal product issues no amount of testing would find.

What to Skip (Even Though It Feels Wrong)

These features feel essential. They're not. Skip every one of them in v1.

Admin panel

Founders love admin panels. Beautiful dashboards showing user counts, revenue, system health. In the first 3 months, you have 10-50 users. You can query the database directly. A basic internal tool (Retool, Directus, or raw SQL) covers 100% of admin needs until you hit 200+ users.

The admin panel for Morta CRM wasn't built until sprint 6 of 12. For the first 5 sprints, we managed everything through direct database access. Nobody missed it.

User roles and permissions

Your first users are admins. They have full access to everything. Role-based access control (RBAC) is a week of development that solves a problem you don't have yet. Add it when your first customer says "I need to give my team member limited access."

Email notifications and preferences

Transactional emails (welcome, password reset) take a day. A notification preferences page with granular controls takes a week. In v1, send the essential transactional emails and nothing else. No weekly digests, no activity summaries, no "someone viewed your profile" notifications.

Onboarding flows

Product tours, tooltip walkthroughs, progress checklists. These are optimization for retention. You can't optimize retention when you have 15 users. Instead, personally onboard your first 20 users via a 15-minute video call. You'll learn more from those calls than any product tour analytics could tell you.

Import/export

"Users will want to import their data from Competitor X." Maybe eventually. But your first users chose you because of a specific problem you solve better. They'll manually enter data for a product that works. Import can wait.

Integrations

Every integration costs EUR 3k-10k in development time. Your first users can survive with copy-paste and manual workflows for 2-3 months. Build integrations when specific customers request specific integrations - and pay for the tier that includes them.

Scoping Process: From Idea to Buildable Feature List

Here's the exact process we run with every client before writing code.

Step 1: Write the one-sentence pitch (30 minutes)

"[Product] helps [specific user] do [specific action] so they can [specific outcome]." If you can't fill in those blanks clearly, you're not ready to build. Go back to customer interviews.

Pushary: "Pushary helps SaaS founders send AI-driven push notifications so they can re-engage users without writing code."

Step 2: List every feature you can think of (1 hour)

Write them all down. Don't filter. Get the full wish list out of your head and onto paper. Most founders have 15-30 features in mind. That's normal and expected.

Step 3: Filter with the first-paying-user test (2 hours)

For each feature, ask: does the first paying user need this to get value? Be honest. "Nice to have" is a no. "Would improve the experience" is a no. Only "can't use the product without it" is a yes.

Step 4: Estimate and cut again (1 hour)

Take the surviving features and estimate development time. If the total exceeds your budget or timeline, cut the least critical items. We cap MVP scope at 6 weeks of development. If it takes longer than 6 weeks, it's not minimal.

Step 5: Sequence the build (1 hour)

Order the remaining features so that each sprint delivers a working product. Sprint 1 should produce something a user can interact with, even if it's ugly. Every sprint after that adds value. This way, if you need to cut the engagement short, you still have a usable product.

The "Just One More Feature" Trap

Every founder hits this moment. Development is going well. The core is built. And then: "What if we also added X? It would make the product so much better."

We have a rule: no new features after the scope is locked. Not because new ideas are bad - they're often great. But because mid-build additions compound in unpredictable ways. That "simple" feature needs database changes, UI work, API modifications, testing, and documentation. It cascades into 3-5x the estimated effort because it touches systems that were already built.

Write the idea down. Ship without it. Add it in v2 when you have user data showing it's needed.

For Pushary, we kept a "v2 list" during the 30-day build. By launch, it had 8 items. After 3 months of user feedback, only 3 of those 8 aligned with what users actually wanted. The other 5 were solutions to problems users didn't have.

How This Looks in Practice: Pushary's First Month

Day 1-7: Authentication (Clerk), database schema (PostgreSQL), campaign creation form, push notification delivery pipeline.

Day 8-14: Automation flows builder (the core differentiator), webhook integrations for triggering flows.

Day 15-21: Analytics (campaign performance), Stripe billing integration, landing page.

Day 22-28: Testing, bug fixes, performance optimization, documentation.

Day 29-30: Deploy to production, first user signups.

30 days. 4 features. Production-ready. Paying users by end of week 5.

If we'd built the original 15-feature scope, we'd have launched in month 4 - and 3 of those 15 features would have been unused.

Frequently Asked Questions

How many features should an MVP have?

3-5 core features that directly enable the primary use case. Anything beyond that is scope creep disguised as "completeness." We launched Pushary with 4 features and validated the business model in under 6 weeks. More features don't mean more value - they mean more time, more bugs, and more diluted focus.

Should I launch my SaaS for free first?

No. Charge from day one, even if it's a discounted "early adopter" price. Free users give unreliable feedback and create support load without revenue. A user paying EUR 29/month will tell you exactly what's wrong with your product because they have skin in the game. If nobody will pay for your MVP, that's critical information you need immediately, not after 6 months of free growth.

How do I decide between building a feature or using a third-party tool?

If it's not your core differentiator, use a third-party tool. Auth (Clerk, Auth0), payments (Stripe), email (Resend, Postmark), analytics (Mixpanel, PostHog), support (Intercom). Every feature you build yourself is a feature you maintain forever. Third-party tools cost EUR 0-100/month at MVP scale and save weeks of development.

What if users ask for features that aren't in the MVP?

Write them down, thank the user, and don't build them yet. Wait until 5+ users independently request the same thing. One user's request is an anecdote. Five users requesting the same feature is a pattern. We keep a "requests" spreadsheet for every product and review it monthly.