Building a SaaS MVP: How to Decide What Goes in Version One

Most SaaS products that fail don't fail because of bad code. They fail because they took too long to reach real users. Here's how we help founders cut an MVP down to what actually matters.

Building a SaaS MVP: How to Decide What Goes in Version One

A founder came to us with a 42-page specification for a SaaS product for managing coaching institutes. Attendance, fees, timetables, parent communication, online tests, a mobile app, a teacher payroll module, a library management system and an inventory tracker. Estimated build time for everything: around ten months.

We suggested building something much smaller first. Version one launched in eleven weeks with attendance, fee tracking and WhatsApp reminders to parents. Within three months, the founder had paying customers, and the feedback was clear: nobody cared about the library module. Several wanted better fee reports, which weren't on the original list at all.

That's the point of an MVP.

What an MVP actually is

A Minimum Viable Product is the smallest version of your product that solves a real problem well enough that people will use it, and ideally pay for it. It's not a prototype or a demo. It should be reliable and pleasant to use. It just does fewer things.

How we cut the scope

1. Name the one core problem. If your product only did one thing, what would it be? For the coaching institute software, it was "institutes lose money because fee collection is chaotic."

2. Map the shortest journey. What's the minimum a customer needs to do to get value? Sign up, add students, record fees, send reminders, see who hasn't paid. That's the MVP.

3. Sort everything else into three buckets.

  • Must have for launch: Without it, the core journey doesn't work.
  • Soon after: Valuable, but customers can live without it for a month or two.
  • Later, maybe: Ideas to validate with real users first.

4. Be ruthless with "must have". The question isn't "would customers like this?" They'd like everything. The question is "would customers refuse to use the product without this?"

Things founders often over-build

  • Complex user roles and permissions. Start with admin and user. Add more when customers ask.
  • Mobile apps. A responsive web app or PWA is usually enough to start.
  • Custom reports. Begin with a few essential reports and a CSV export.
  • Integrations with everything. Pick the one or two integrations your first customers actually need.
  • Elaborate onboarding. In early days, you'll onboard customers personally anyway, and learn a lot from it.

Things founders often under-build

  • Billing and subscriptions. If you want people to pay, make paying easy. Use a payment gateway's subscription features rather than building your own.
  • Data security. Multi-tenant isolation, backups and access control need to be right from the start, because fixing them later is painful.
  • Basic analytics. You need to know what features people use.
  • Support channel. A simple way for users to report problems and ask questions.

Technical choices for an MVP

Pick boring, proven technology your team knows well. A standard framework like Laravel or CodeIgniter with MySQL, hosted on a reliable VPS or cloud setup, will take most SaaS products a long way. The product rarely fails because the stack wasn't trendy enough.

After launch

Talk to every early customer. Watch how they use the product. Track which features get used. Then let that drive version two. The founders who succeed are the ones who treat the MVP as the beginning of a conversation with customers, not the end of a build.

Y
Written by the YPage Technologies team

We design and build websites, web applications and SaaS products for growing businesses, and share what we learn along the way.

Work with us

Ready to start your next project?

Let's talk about your website, web app or digital product.

Get in touch