Hey all,
Welcome to part 3 of Building 101 🎓, this time we’re looking at building MVPs - ‘Minimum Viable Products’.
Let’s jump in… ⬇️
What does ‘minimum’ mean? Getting brutal with your idea of what it means to solve a problem.
Technical decision-making: Prioritising speed over scalability.
Doing things that don’t scale: Doing things manually at the start, and automating later.
1. What does ‘minimum’ mean?
“What would you give to someone if their hair was on fire?”
This is the question asked by Michael Seibel (founder of Twitch) when articulating what an MVP is.
He asks founders - “How would you solve that person’s problem?” Most people will suggest a bucket of water - that’s the perfect solution. But if you went off to go and get a bucket of water, you’d be too late. In reality, you’d use literally anything around you - even if it meant rubbing a brick across their hair to put the fire out.
It’s a crude analogy but the brick is your MVP - it’s the literal simplest thing you could use to solve the problem. A lot of people are scared by this idea and spend months building the perfect solution without it ever seeing daylight.
But in reality, it’s not so unfamiliar:
The first iPhone had no video. It had no app store and only supported 2G internet at a time when 3G had already been a thing for 4 years!
Airbnb initially had no payments. It was only marketed for people needing an air bed to sleep on around work conferences.
Stripe had no banking integration at launch. The team would spend hours after dark manually filling paperwork for new accounts.
(The Airbnb example is my favourite - how niche is that?! 😂)
If you find yourself months into an MVP build, take some time to reflect on what your idea of ‘minimum’ really is.
I already know what my product should do, just let me build it! - Anonymous first time builder
It’s valid to be this brutal to start with. That’s because your first few users (the ones with their hair on fire…) are ‘early adopters’ - they need a solution, not sophistication.
2. Technical decision making
In today’s world, the market provides us with a sliding scale by which we can decide how much code we want to write.
When building an MVP, we should always be making technical decisions from the point of view of speed over scalability. There are 3 approaches I think all builders should think about before writing a single line of code.
No-code solutions
Firstly, can your solution be built without any code at all?
Maintaining code is like being in a very clingy relationship - it needs constant attention and monitoring. If you ignore it for too long it will start to misbehave and eventually cause you problems. Plus - you’re the only one who can fix it.
In those early days, you want to be spending as much time as you can speaking to customers and obsessing over your core value proposition - not worrying about bugs.
Here are some examples of real businesses that started out on no-code platforms:
Dividend (Bubble)
As a new-era lender of financing for clean-tech home improvement, and having raised over $365M in venture funding to date, Dividend is probably the most successful company to take its first steps with a no-code solution.Teal (Bubble, WebFlow, AirTable, Zapier)
Teal is a job search platform that provides a great example of how no-code tools can be combined to build out a fully-featured solution.LetterHunt (Softr)
An example of a niche platform for newsletter growth that achieved multiple #1’s on Product Hunt, entirely with no-code.
There’s a real use case for no-code tools, here’s what I think most builders should be looking to use if they’ve decided no-code is for them:
So - if it’s possible to build your MVP with no-code you definitely should!
PaaS (Platform-as-a-Service) solutions
There are plenty of cases where what you're trying to build will require you to write at least some code.
It could be the case that your product is your code, for example, a proprietary analytics engine, or it could be that you're addressing a solution marketplace that is as yet untouched by no-code, like browser extensions.
In all cases where we do have to write code though, we should aim to write as little as possible.
One way of doing this is by using a PaaS solution. The best platforms I have used when building my own products are Supabase and Firebase.
Both offer part-solutions for a particular segment of your tech stack such as authentication or data storage. Firebase just tips the scales with its wider range of features including push notifications and analytics, deployment management and simple integration with every other Google product on the planet...
Commonly, these solutions are used as standalone backends supporting a custom frontend application built with a JavaScript framework like Next.JS or a mobile development framework like Flutter.
Designing your tech stack this way is beneficial as you only code the easy stuff (your frontend) and can abstract away the difficulties of server and database management to 3rd parties.
A note on mobile apps - always use a cross-platform framework like Flutter to avoid separate codebases for iOS and Android. Remember - we’re focusing on speed!
IaaS (Infrastructure-as-a-Service) platforms
TLDR: Basically never use these for an MVP.
The most common IaaS platforms are Amazon Web Services (AWS), Azure and Google Cloud Platform (GCP) and they all offer solutions for a very niche part of your tech stack like networking, security and access management or databases.
These are enterprise-grade platforms for building at scale requiring lots of code and configuration - they shouldn’t be touched at the MVP stage.
Moving on.
3. Doing things that don’t scale
If you haven’t noticed already, we’re focusing on speed. That means sacrificing automation until your product is ready for the floodgates to open.
Here are 5 things you should do manually at the MVP stage:
(Note: If a no-code solution can do these for you - then fine, use it!)
- Billing management
First of all - use Stripe (duh…)
If you building an MVP, you should hopefully know who your initial users are going to be. Instead of wasting time writing an integration, just create accounts and manage billing cycles and invoices manually.
- Customer signup
While implementing this doesn’t take that long nowadays - in a similar vein to billing, create accounts for customers manually through your platform of choice and don’t write any code to automate this through a signup page.
- Email automation
Early on, it pays to get personal with your customers, so email them yourself!
Save yourself time in integrating with a mail provider and get back to building your core features!
- Marketing
Paid ads are hard to get right for new products.
And the time and money are best spent elsewhere on rewarding customers for interviews (everyone loves an Amazon gift card…), engaging in networking events and building up a social presence.
- Testing automation
At scale, it pays to automate testing as it can massively improve reliability and speed up the development of new features.
But when you're building an MVP your solution will change so fast that you’ll be re-writing this almost daily.
Kick that can down the road!
Round up
That's it! Hopefully the discussions I've gone through can help you when deciding on the steps to take when building your MVP!
If you enjoyed this post, let me know in the comments!
IdeaHub is a newsletter for tech peeps who want to learn about building their own tech products.
Weekly emails discuss the full product process including idea generation and validation, building MVPs, and strategies to get more customers.
Top comments (0)