Making an MVP Project

It’s my 6th week here at Hackreactor remote and I had the opportunity to build an

MVP (Minimum viable product) in 36 hours solo. This is the biggest project I’ve undertaken so far in my experience with writing software. This was a great learning experience to see not only what I was capable of making but also what amazing things my peers could make. I leveled up in many exercises throughout sprint including design, approach and scoping. I’m going to tell you about my experience and all the lessons learned.


The best way to start is by writing out everything you’ll want of the project. Every major fixture and the expected functionality. By doing this you set a clear path on what to design and can start making a ‘wish list’ from the functionality you have. As I learned often you’re not going to hit all the goals in your application. It’s essential to be very lean about what is the project and choose from your ‘wish list’ when you’ve finished with the minimum requirements.


The second biggest takeaway I have for you is: favor function over form. To be timely in development of an MVP this essential. You need to be able to pivot if components of your app aren’t working as intended. Focus on the view at the very end. CSS and all the polish in the world can’t make your non-functioning project presentable. Often the tiny bits of polish can be very technical and take away a lot of your much needed attention to detail on the heart of your app. Get the boilerplate up before you polish.


If you’re going for a full stack application deploy immediately. It’s a lot easier to trouble shoot issues incrementally than deploy to Heroku or AWS and have a hundred plus lines to review. After you deploy start a local server and do all your testing there. In theory the server on the deployment site will be the same as a local version without the need for an update/rebuild of an instance. You bank precious time and can rapidly iterate over your design process in this way.


The last and arguably most important is to make small changes and test often. By redeploying to your hosted site every so often you can catch bugs as they’re created and get them off your radar fast. It also is extremely helpful if you’re not approaching the MVP with testing frameworks and have a hard deadline. When creating something new by yourself and adding all kinds of features through the application it’s easy to get lost. In software there are a lot of moving parts and checking in on them is good pattern to follow by any means.


I hope these lessons I learned help you in your development process. The main idea is to cut as many corners as safely as possible. With these tips you can make deadlines less intimidating. Stage your ideas and checkin as often as possible to make sure you’re on target. As always thank you for reading.