One thing we love doing at Mayfly is giving founders clear formulas and decision-making frameworks to break through analysis paralysis and keep the rocket ship firing.

A massive decision that holds many founders in a paralysing state of uncertainty is asking how basic can and should my MVP be.

There are two key spectrums that founders can place themselves on which determine how basic their MVP is. Firstly functionality and feature set richness and secondly, tech stack.

‍

‍

Let’s start with how basic can my MVP be

In 2021, Kim Teo’s startup Mr Yum, raised the biggest Series A for a female founder in Australian history. What if I told you that the Mr. Yum team built their MVP in two weeks at no cost? The problem Mr. Yum was trying to solve is foodies want to look at photos of their food before ordering. The MVP: Go to some local cafes, take photos of the dishes, place the photos on an Airtable doc, link that doc to a QR code, and stick the QR codes on the cafe tables.

‍

I recently came past a founder generating hundreds of thousands in revenue by building an interactive game using Typeform.

With the wealth of amazing software tools available today, most app ideas I come across, I can think of a version of an MVP that can be built at no cost in a weekend which will be feature rich, but can deliver on a UVP. I’m talking; wanna build a jobs marketplace? Create a Facebook group. Want to build a Project Management Tool? Maybe a notion table with a Calendly integration does it.

On the other side of the spectrum is spending 2 years and a million bucks having a team of developers code up every feature you’ve ever thought of. Sitting in the middle is no code apps, which is taking the app development world by storm. With founders creating incredible apps in a fraction of the time and cost of traditional development. More on that here.

When we run the Mayfly idea to launch workshop, we do an exercise where we encourage founders to think of what the most basic version of their MVP can be. The reason we do this, is a common mistake founders take too long and spend too much money building their MVP. But just because there is a super basic way of building your MVP, it doesn’t mean that is the route you should go down.

‍

How basic should my MVP be?

Let’s answer the tech stack question first. To do this, let’s understand the landscape, and then ask ourselves a series of questions to work out where we sit in the landscape.

These are the questions to ask to determine which column you sit in.

How much budget do you have? If you have no money, you don’t have much choice. Super basic it is. If you do have millions of dollars in the bank, going traditional code may be appealing, but going no code will save you a lot of money which can be used towards user adoption.

What is your appetite for risk? The less risk you are willing to take, the more you should go for super basic or no code.

What is your skill set? If you have great development skills, you may be able to get an amazing app built at a lower cost.

How well validated is your idea? Dropbox had a waiting list of over 100k people. At that point, you should build a high-quality MVP which is highly scalable.

Who is your customer? An enterprise customer won’t want a super basic MVP, while if you wanted to create a platform showing the cheapest beer in your local suburb, your customer might be ok with a notion doc.

How many competitors do you have? If you don’t have a strong unique value proposition, you need to rely on marketing and an incredible product experience to win over users so a super basic MVP will not do.

At the end of the day, you need to ask yourself what version of your Minimum Viable Product is actually viable. Viable means it’s good enough to attract early adopters which can prove that your product is solving their problems.

As for feature sets, one of the easiest ways to reduce your time and cost to launch is to cut unnecessary features that don’t deliver on your UVP. There is always a gap between the features and functionality you think your users will want and the features and functionality they actually use and want. It’s generally best to cut out bell and whistle features and iterate your product based on your customer’s feedback and not based on your assumptions.

Use this tool to help calculate how basic your MVP should be.

For more guidance on this topic, book in a free call with someone in the Mayfly product strategy team.

‍