It’s inevitable that as a developer, at some point in your career you will be asked to build an MVP. An MVP — Minimum Viable Product — is a version of a new product that only contains the essential features needed for the early adopters. From my experience it is actually really hard to build an successful MVP without being caught in some very enticing traps. I want to share in this articles some of the more common pitfalls to avoid when setting out to build an MVP so hopefully your project can end up being successful.
Setting up a good development environment is important. It a developer can get the application up and running locally in a couple of seconds then over the course of an app development cycle it could save a mass of time as well as plenty of frustration.
However, when working on an MVP you have to be a little careful. Sure you want the app to spin up fast locally and you want the developers to have a beautiful dx (developer experience) but you have to be very wary of this rabbit hole. And a rabbit hole it is!
You can go to town tweaking you dev environment if you are not careful. Using different libraries mixed with different scripts to do clever things to get the dx just right is an all too enticing temptation for a developer and one that must be treated with caution on an MVP. You must remember that this MVP might not even be around in 6 months so don’t waste time on things that will not add to the essential features of the application.
I will admit that I have been caught by this one multiple times when working on MVPs. I am a frontend engineer by trade and I am a sucker for a beautiful and elegant UI. In fact I think it can make or break an app. If the UI is crap then people will just not want to use it and then your app will fail.
However, there is a difference between usable and beautiful. An app can be usable and not beautiful. An app can be beautiful and not usable. In an MVP your app needs to be usable. That is all you have to focus on.
It doesn’t matter if the input field looks horrendous. It doesn’t matter if the elements in the navigation don’t quite line up. It doesn’t matter if you just use the word ‘Loading’ instead of using a loader. (Please bear in mind as a frontend guy I still cry inside when I see these things, I just have to remember the broader picture and that we are building an MVP). What matters is its usable and clear to the user what the app can and can’t do.
An MVP by its very definition should stick to the bare essentials of what is needed for its early adopters. Nothing more. This is really difficult to stick to especially when working in a team of developers.
It’s all too tempting to start adding in little useful features for the users. It’s also easy for users to ask for things that are ‘nice to have’ but not ‘essential’. The line between ‘nice to have’ and ‘essential’ can often be quite blurry also.
However, if you’re building a true MVP then really try to stick to the essential features as much as possible. This will not only speed up delivery but it will enable you to test out the core features sooner to see if this product really has the ingredients to be successful.
Getting regular and rapid feedback is also a key element of building an MVP. It’s the exact opposite of developing something in secret for months and revealing it all sparkly and beautiful at the end. Building an MVP is basically building something in public. It gets full exposure from the start of its life in order to help shape it into something that is actually useful.
If you don’t get regular and rapid feedback you run the risk of going down fruitless avenues, of building features that no one will use and are not needed, of wasting time that you just don’t have.
When building an MVP — build, release and then show to the user and get there feedback. Get business’s feedback. Get other developers feedback. This will help you stay on course and build something that is actually what the user not only wants but needs.
I always thought that building an MVP was easy because you could build something quick and not have to worry too much about how it looked. But in reality it is really hard to do, especially in an organisation where you are working with others.
With an MVP you’re trying to build something that can test out the main features of an App with the possibility that this will turn into a production quality app. There are many pitfalls you definitely want to avoid and I have tried to lay out the main ones in this article. I hope this article helps and I would like to hear any tips you may have when building out an MVP.
If you found this blog post helpful, why not stay updated with my latest content? Subscribe to receive email notifications every time I publish. New posts go live every Monday at 8:30 AM Central European Time.
By subscribing, you’ll get:
Exciting Discoveries: Be the first to know about the latest tools and libraries.
How-To Guides: Step-by-step articles to enhance your development skills.
Opinion Pieces: Thought-provoking insights into the world of frontend development.
I live in the vibrant city of Prague, Czech Republic, with my family. My blog is more than just articles; it’s a community of like-minded developers who share a love for innovation and learning.
I’m a passionate Frontend Developer specialising in React and TypeScript. My professional journey revolves around exploring and mastering new tools and libraries within the JavaScript ecosystem.
Check out the original blog post on my blog.
No posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.