Things to avoid while building MVP

In August I’ll join Antler startup accelerator program in Stockholm which is aimed to help to find co-founders and found a startup.

As a technical co-founder, it’s important to make an MVP most effectively. This blog post would be a reminder for me about things that should be avoided.

Use boring stack

Use stack that you have the most experience with. It might be not the most suited stack out there to solve the problem, but it’s very likely the most efficient one in terms of product delivery speed. After all, you’re building an MVP. It shouldn’t be the optimal solution, just the fastest one to implement.

Boring stacks tend to have less unknows because they’re old and you’ve already worked with them. Check also great Dan McKinley’s essay Choose boring technology.

Don’t overengineer

Stick to your stack as much as possible and avoid adding new technologies and programming languages.

Do you think you absolutely need to add RabbitMQ for queueing messages and React + Redux for rendering UI? No, you probably would be better off implementing that using your current stack. For example, a message queue could be stored in MySQL and the UI could be rendered in a plain HTML with a touch of JS.

Don’t learn new technologies

It’s totally fine and even great if you want to learn new technologies. Just be honest with yourself: do you really want to build a product to validate your idea or are you building it just for fun and to learn new technologies? Several times I fell into that trap: I thought I was doing the former, but in reality, it was the latter. Try to avoid that while building an MVP. I know how tempting that might be.

Don’t overoptimize

Skip everything that doesn’t bring value to your customer or improves product delivery speed.

No, minifying frontend assets or implementing backend cache to improve the loading speed of your web service by 10% isn’t bringing value. Nor setting up a CI/CD pipeline to make automated zero-downtime deployment.

Don’t automate

Don’t automate tasks that didn’t get repetitive yet.

In Notifier, I needed to let users change and cancel their subscriptions. I started to think about the UI and backend implementation. But hey, I don’t have that many users and subscription change isn’t what they do often. So I just added mailto links on the profile and pricing pages. A user could click that link to send me an email with a predefined text, and I can change their subscription manually. Which took like 15 minutes to implement and saved me at least a few hours implementing subscription change properly.

Use 3rd-party solutions

If integrating a 3rd-party solution takes less time that implementing some functionality yourself then you should probably go for it. There are a bunch of services waiting to make your life easier and implement some part of your service themselves. Be it hosting, forms processing, sending marketing emails, or anything else. In terms of money, it’ll cost more but it’ll save your precious time which is more valuable at this point.

Don’t code (if you can)

In the last couple of years, there is a rise of no-code platforms, which let you create web services and apps without coding. This is still something I want to explore, so can’t really recommend anything yet. As a starting point, you might check a tutorial about building an Airbnb-like mobile app.

Example

Let’s say you’ve got a hypothesis that people would like to book talk sessions with various specialists, from software developers to farmers. And you even came up with a name for it — OfficeHours365. Let’s start unwrapping how an MVP might look like.

The most obvious way is to build an app where specialists could create their profiles and enter their availability time. The app lets customers search needed specialist, chat with them to discuss details, and pay for sessions via Stripe. The sessions could be held via Skype as building a video chat would take to much time. Seems like an ideal MVP that has only the most needed features to test the hypothesis.

In fact, it is not. Very likely you’ll spend quite some time building the app and end up with a platform with no specialist because they don’t want to spend their time signing up since you have no customers for them. Customers won’t use your app either because, well, there is no one to talk to.

What could be done better:

• Instead of waiting for specialists to sign up contact them yourself and get a dozen interested specialist and create profiles for them: a photo, description, hourly rate, availability.
• Get rid off all features. Just a plain static page with a listing of specialist profiles. A session book button might be as simple as a mailto link to send you an email. Or you might use a 3rd-party service for scheduling meetings.
• Focus only on one specialist type. For example, software developers or travelers. It’ll be easier to attract customers and test different marketing channels.
• Usually, people want to have specific questions answered, not just chat about stuff. Research which are the most asked questions in your field and list them on the landing page. So customers will see that you know their needs and issues.
• Last but not least, talk to your lawyer. Microsoft probably won’t be happy about name OfficeHours365 you came up with.