Things to avoid while building MVP

In August I’ll join the Antler startup accelerator program in Stockholm, which is aimed at helping people find co-founders and start a company.

As a technical co-founder, it’s important to build an MVP as effectively as possible. This blog post is a reminder to myself about the things I should avoid.

Use a boring stack

Use the stack you already have the most experience with. It might not be the “perfect” stack to solve the problem, but it’ll almost always be the most efficient in terms of product delivery speed. After all, you’re building an MVP. It doesn’t need to be the optimal solution — just the fastest one to implement.

Boring stacks usually have fewer unknowns because they’ve been around longer and you’ve probably worked with them before. Also check out Dan McKinley’s great essay Choose boring technology.

Don’t overengineer

Stick to your stack as much as possible and avoid piling on new technologies and languages.

Think you absolutely need RabbitMQ for queueing messages and React + Redux for rendering the UI? Probably not. You’re better off implementing that using what you already have. For example, a message queue could live in MySQL and the UI could be rendered in plain HTML with a touch of JS.

Don’t learn new technologies

Learning new tech is great — just be honest with yourself. Are you trying to validate your idea, or are you secretly just building something for fun to learn new tools? I’ve fallen into that trap a few times. I thought I was doing the former, but in reality, I was doing the latter. Try to avoid that when building an MVP, no matter how tempting it is.

Don’t overoptimize

Skip everything that doesn’t add value to the customer or speed up product delivery.

No, minifying frontend assets or caching the backend to improve load speed by 10% doesn’t really add value. Neither does setting up a fancy CI/CD pipeline for automated zero-downtime deploys at this stage.

Don’t automate

Don’t automate tasks that aren’t repetitive yet.

For example, in Notifier, I needed a way for users to change or cancel their subscriptions. I started planning the UI and backend… but then realized I didn’t have that many users, and subscription changes weren’t that common. So instead, I just added mailto links on the profile and pricing pages. Users could click the link to send me an email with a predefined text, and I’d change their subscription manually. Took me 15 minutes to implement and saved hours of unnecessary work.

Use 3rd-party solutions

If integrating a 3rd-party solution takes less time than building it yourself, use it. There are tons of services out there that want to make your life easier — whether it’s hosting, forms, email marketing, or pretty much anything else.

Sure, it’ll cost money, but it’ll save you time, which is far more valuable at this stage.

Don’t code (if you can)

No-code platforms have been on the rise in recent years. They let you build web apps and services without writing much code. I still want to explore this area more, so I can’t recommend specific platforms yet, but here’s a starting point: a tutorial on building an Airbnb-like mobile app.

Example

Let’s say you have a hypothesis that people would like to book talk sessions with specialists — from software developers to farmers. You even came up with a name: OfficeHours365.

The obvious way would be to build an app where specialists create profiles and set availability. Customers can search, chat with them, and pay via Stripe. Sessions could happen over Skype, since building your own video chat would take too much time. Sounds like a lean MVP, right?

In reality, probably not. You’d spend weeks building the app, only to end up with no specialists (because they don’t want to sign up if you have no customers) and no customers (because there are no specialists). Classic chicken-and-egg problem.

Here’s how it could be done better: