Have you ever had a project idea, which seems small at first, but grows exponentially as you start working on it? And of course, sooner or later interest gets lost and you switch to something else. Eventually, you end up with a bunch of half-finished projects that you can’t really show or even gather feedback.
Yes, I’m sure we’ve all been there.
Recently, I released OhCrash — a product I started on Wednesday and published later that same week on Saturday. So when I got asked "How are you so productive with MVPs?", I thought it would be a good idea to share my "secrets". There’s no trickery involved, it’s just a set of rules I stick to, in order to move fast.
This one is the most important. No matter how productive you are with code or how many shortcuts you’ve got, it will be very hard to keep focus on a big target.
Choose the smallest product idea you have in your todo list and go with that. It will be tempting to add more features, but don’t do it. Put it in your todo list instead. I use GitHub Issues to keep track of the stuff I need to do.
It is crucial to define the MVP line you can’t cross. List features that are absolutely necessary to deliver initial value and gather feedback.
You can always build more features. But for now, simply postpone them.
It is also incredibly important to choose an idea you are actually excited about and will use the finished product yourself.
I don’t start writing a line of HTML/CSS until I’ve got at least a rough sketch in my head or on paper (preferably). I turn on my favorite up-beat music and draw in the notepad. Try to make sketches for the key pages, no need to draw all of them.
This rule helps me to code the design in no time, because I don’t need to think how it should look and where these elements should be.
At this moment you should be aware what exactly should be built. I recommend splitting goals into many small, individual tasks, which look achievable. When you complete these tasks, you get a feeling that a progress is happening and you are getting closer to the finish line. And it is actually true!
For example, "Design homepage" is a goal. But it can be split up into many small tasks, like:
Always keep essential functionality at the beginning of the queue. You won’t go far if you keep working on fixing the alignment of text, while authentication of users does not work.
Get essential functionality done and move on to fixing issues afterwards.
Stick to the toolset you use every day and are comfortable with. Don’t choose that new framework, because it’s trending and "everyone" uses it. You won’t be productive, if you decide to kick off a project with a tool you are trying out for the first time.
Don’t get me wrong, trying new stuff is great, but you mustn’t do that when you want to complete your project idea.
Allocate some other time for experiments, now you need to build & ship.
Reuse your code and folder structure across all projects. This is a key to rapid completion of your idea. Extract as much as possible into standalone building blocks, which you can easily install and use immediately.
Even when it comes to folder structure and file organization, I highly recommend making a Yeoman generator for quickly scaffolding out necessary parts.
I’m also planning to release my generators for React + Redux apps soon, so that you can build faster too.
Yes, I strongly encourage you to try to build server-less apps, that contain most of their logic on the client’s side. At the MVP stage, you shouldn’t worry about servers, hosting, data storage, deployment, etc.
Use Firebase. Thanks to Firebase I can build & ship faster than ever before. It has a few things I don’t like, but it’s nothing compared to what I get:
And all this is for $5 per month. It is very hard now to go back after trying out Firebase.
If you still need to have a server for tasks that just can’t be executed on the client side, don’t worry, there’s a "workaround" to provide you with great experience for almost no costs. The answer is DigitalOcean + Dokku. Dokku is an open-source alternative to Heroku, that provides almost the same flow of deployment via git push.
Of course, if Heroku pricing plans don’t scare you off, you’d better go with that instead.
Note, don’t try to handle and prevent problems like scaling, security updates, server maintenance at this stage. Keep in mind, you need to keep moving constantly, otherwise you’ll fail fast.
Remember, as your project grows and gains traction, you can always migrate to something else.
Final advice, don’t switch to another project until the MVP of your current idea is shipped. Otherwise, you’ll end up right where you started. Try to build up an attitude to finish one thing before moving on. It will pay off.
This set of rules really helped to deliver more stuff than ever before. Just looking at the side projects, I shipped initial versions of Bucket and OhCrash within last 2 weeks. I hope this short write-up will be helpful for you in building all those great ideas you've written down in your todo list!Back to all posts