John Kueh
October 04, 2019

How to build an MVP?

My workflow to plan, build and launch an MVP

Hi everyone, it's John.

I am in the progress of launching an MVP for MetricsJar, and this blog post explains how I plan, and build it. Heads up - I am a software engineer, so my way of building MVP might not suit everyone.

What is an MVP?

MVP - Minimum viable product. It's the smallest version of your product that you launch to start collecting feedback from early users. Instead of waiting for perfection, you launch a 'lite' version, collect feedback, and continuously iterate to make it better over time.

There's a wide range of MVPs. Some people launch without writing code, using web builders and tools linked up with Zapier. Technical folks usually writes some code, but just enough for a solution to a particular problem.

Things to do before building

Planning and building the MVP can take up to a few weeks... Here are some marketing tasks that I do before going deep into it:

First - buy domain (try to get a .com eg.

Then, set up an early access form with Mailchimp

At this point, I dont really care about the look and feel of this form. I want only the really interested guys to sign up

After that, make landing page, add the form above to landing page

Make it nice and clean, make sure it doesn't feel like a templated page. You still want to catch some attention.

Post landing page to Indie Hackers, BetaList, friends and family etc...

Always try to respond to comments as fast as you can

Setup blog, add blog to landing page and post to Indie Hackers, BetaList, friends and family etc. Rememeber to add Google Analytics to both landing page and blog so you can measure traffic. Write one blog post every week, with valuable content for your audience.

Finally, add meta tags, og tags (this is a good guide) and submit your sitemap to Google Search Console.

Getting these out there enables you to start collecting emails and for Google to start ranking you.

Google started to rank my Indie Hacker posts and Twitter page after just a few days
Just a few days in, people started signing up to an early access list from reading my posts on Indie Hackers

Planning the MVP

You need a project management tool to store all your features. Trello is a great free choice. I use GitHub a lot, and they have a free project board called GitHub Projects - so I use this. Here's an example of my project board:

I try to write out all the features as User Stories

I set up my project board kanban-style. There are 3 most essential columns:

  • Backlog
  • In progress
  • Done

Backlog is where you put all the tasks that are ready to be picked up. For MetricsJar, I decided to have 2 backlogs at the moment. One for the MVP at launch, another for v2 one month after. I like having 2 backlog columns - I drag tasks that are not 100% needed at launch into the v2 column.

I write most features as user stories. It helps keep the task concise. There is only so much you can write in a sentence of user story.

As a user, I should ...

As a user, given ... I should ...

It's okay to have non user story tasks sometimes 😂

Building the MVP

Before I start working on a task, I grab it and drag it into the In progress column. While working, I sometimes find that the task is too big for a single work session. If that's the case, I break it up into multiple user stories. It is good to have small workable tasks to feel progress.

Once a task is done, I move it to the Done column. I like adding my pull requests/commits to the task as a future reference. GitHub project makes this very easy.

Column of Done features

The MVP should only include the minimum features required to solve the problem for your users. You are using this to test if whatever you make creates value for your end-users. That is why I like having 2 backlog columns. Move unneeded features to the v2 column.

For the MVP, UX is a lot more critical than visual design. To provide good UX, I usually use a design system like Tailwind. A design system keeps your interface consistent and pleasing without much effort. However, I feel that visual design like branding and colors, etc. is not super important at this stage. Don't spend too much time on that.

Design systems like Tailwind enables you to use these helper classes which makes it easy get a product up quickly

I like making the frontend of the product first. I usually code it in React. I use mocked data and work on building a clickable prototype, which clearly shows how a user can use the app. This prototype is used for demos or to make GIFs and videos for sharing with initial users.

Example of a clickable prototype (no backend) that demonstrates a working feature

Once you have something up and running, don't be shy to show it around to friends, family, or anyone to collect feedback and things you can improve on. Other people can notice confusing copy / UX a lot better than you because they have never seen/use your product before.

Before feedback
Feedback from an Indie Hacker user
After feedback

I only start working on the backend - API, models, database side of things when I've shown the prototype around a bit and have a bit more confidence to start building it out.

For the backend - choose a language/framework that enables you to build out features quickly. For me, its Node.js along with the Serverless framework and deployed on AWS (Amazon web services).

Other good stack choices for building MVPs are:

  • JAMStack - A headless CMS + Next.js / Gatsby frontend
  • Ruby on Rails
  • Django (Python)

My craft is software engineering - that is why I choose to code up my MVP from scratch. If you are not an engineer, there are a lot of no-code options that you can use to build your MVP:

It is better to build the MVP yourself rather than outsourcing it. This is because you need to make quick iterative changes as you learn from your users. Quick changes are hard when you rely on an outsourced person that is charging you by the hour.

Another reason to build the backend last is because it's hard to make quick changes once it's done. It's so much easier to mess around with mockups and clickable prototypes than to redesign a database/API schema.

Launching the MVP

The MVP for MetricsJar is not ready yet. The plan is to launch and invite the first batch of beta users in December and then write a post about launching!

Like this article?
Join our community on Twitter to discuss this article.
Copyright © 2019 MetricsJar
Privacy policyTwitterGet in touch