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. www.metricsjar.com)
Then, set up an early access form with Mailchimp
After that, make landing page, add the form above to landing page
Post landing page to Indie Hackers, BetaList, friends and family etc...
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.
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 set up my project board kanban-style. There are 3 most essential columns:
- In progress
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 ...
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.
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.
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.
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.
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!