MVP

MVP


"How to MVP" - a guide to efficient software project MVP development


Hey everyone!


Quite often startups die before launch. I’ve met many founders struggling with MVP launch for months, sometimes years. I believed I knew how to fix it, but back when I was just a freelance developer, I had insufficient authority to persuade founders to fix the mistakes they make. That’s why I founded a software development agency focused on early-stage projects development and management.


We faced all kinds of development-related issues popping up on pre-release stages on various projects. I'm pretty sure SUS lessons will not cover such a specific topic. So, I've put together some notes on how not to end up in development hell and release your MVP in weeks, not months or years. If you're gonna like it, I’ll make a proper article out of these quick notes.


A minimum viable product (MVP) is a product with just enough features to satisfy early customers and to provide feedback for future product development. This reading supposes to help you avoid common mistakes on your way from idea to MVP.


Things to do:


Setup automated deployments (aka CD, Continuous Deployment) as early as possible. It will save you countless hours. Full setup for a web app and microservices/serverless/monolithic backend should take just around 20hr, so it’s definitely worth it.

Manifest your product value proposition and make sure everyone on your team remembers it all the time. It’s important in terms of development efficiency because you’ll avoid unintentional wandering away from your goal. YC covers this one very well, so you’ll hear the rest from them.

Answer this question every time before including yet another feature in your MVP scope: "Can this project provide its core value without this feature?". If the answer is "yes", then postpone this feature development until your MVP is out.

Use mainstream design systems like Material UI. First of all, the mainstream design systems are something your users have seen already and therefore they'll have much less overhead understanding your UX. Second, mainstream design systems are already developed. Just pick an existing UI framework and use it - it's literally 10 times faster than developing custom UI. And third, man, I bet your main value proposition is not your product design uniqueness, so quit worrying about it and focus on the one most important thing your product does.

Create a prototype (interactive designs) before starting the development and show it to potential users. This will save you months, literally. A good designer can put together your MVP prototype within just a few dozens of hours.

Try to fit your MVP development within 6 weeks. This is enough time to write the code carefully and not too much time to procrastinate. Can't fit? Scrap unnecessary features, I bet you have plenty of them.

Use mainstream techs when they fit you. Mainstream techs are mainstream because they are usable for a wide variety of cases. Do not try to optimize your tech stack, unless maximal software performance is your main value proposition. Even if you are not gonna pivot your business idea you will change a lot in your software, trust me. If you are considering equally fitting mainstream techs, choose the one that is easier to maintain.

Use Docker to make your local dev environment work identically on every team member's machine. Make sure the local environment can be launched with a single bash command.

Use scrum. Read Jeff Sutherland's book and stick to its guidelines - that all you need for now.

Use Gitlab. It provides you with all you need for task management, code versioning, CI/CD, etc. We've managed to reduce the number of tools we use for project management to just 3: Slack, Google suite and Gitlab.

Use monorepo over multiple repositories. There are many advantages, but the most important ones are: it’s easier to manage features delivering, versioning and CD setup.

Always record new features ideas and put them in the log

Report Page