When to launch the MVP for your SaaS application?

When to launch the MVP for your SaaS application?

When you start building a new digital platform, there is always a long wish list of features... how do you approach this challenge and how do you know when the MVP is ready to launch?


When you start building a new digital platform, whether it's a customer portal or software as a service application, there is always a long wishlist of features, like it's never-ending, right?

So how do you approach this challenge and how do you know when the minimum viable product is ready to launch?

In this article & video, I'll share a couple of options depending on the type of product you're launching and how familiar your audience is with your service.

Let's get to it.

Over the years, I've delivered many digital platforms for clients. Those clients - either startups or corporate organisations - usually come to us with a great idea for a new digital platform and a very valid business model.

However, the wishlist of features to be built is either way too long, or sometimes even too simplistic where they haven't thought about the basic admin moderation tools, for example, or the back-office processes and how or what needs to work in the real world, in a production environment.

As you start building on your idea, your stakeholders or investors might want to start pencilling in a date for the launch. Following best practices, you will then start with a sprint zero with a focus on the user experience research, the planning, validating the ideas and documenting to user journeys, and the back-office processes...

You need all of that to then start moving on to development sprints, where you iterate over the features. You'll keep working with the UX and Quality Assurance teams to ensure consistency and that your service / product is answering user needs.

But how long are you supposed to be building? How many development sprints will it take to launch something? That's a genuine question.

What I've discovered is that it really depends on if you're building a brand new product / service, or if you're replacing a legacy system that is already running.

Launching a new product

If you're launching something new, I would recommend going live with your product whenever the end-user - the customer - would feel that they receive some value from the service.

In those situations, there might still be a lot of manual steps in the backend for you, for your business, for your team to process the data, produce the reports in a manual way. However, this is going to be very low scale at the beginning, you won't have hundreds and thousands of users, so you will be able to cope.

This is very important because you're still validating your product market fit. There's no point automating the whole end to end process if you need to pivot in a few weeks/months when you realise that the users don't really want the service that you're building.

Replacing a legacy system

The second option, when replacing a legacy system, means you already have - you already know - there is demand. I'm not saying you can disregard the end-user experience at all, far from that, but you already know what users are doing, what they need, the data they have available and how you process it.

In this situation, the timing of launching the minimum valuable product is whenever it makes life easier for the admin users behind the scenes. The goal of the product will be to reduce the manual back-office processes and to try and automate as much of their workload as possible so you can scale.... that's the main point!

Those are the two main differences we've seen launching new products for startups or corporate organisations alike.

Going live

Going live is always thought of as a scary milestone where everything has to be perfect and fully automated, fully tested, before putting it in front of a single client, in front of real users.

But to be honest, I've never seen a product launching too early. There is always that advantage of getting feedback as soon as possible.

So what do you think? Let me know in the comments below if you've experienced this in your recent digital project and how you dealt with it.

I hope you found this useful and if you want to hear more tips like this, just get in touch. Don't forget to subscribe to my YouTube channel and follow me on Twitter to keep learning with me and grow your career in digital.

Until next time, stay safe and see you soon.

Jump to: