MAKE - Build
OK, so you have an idea. We'll now discuss how to build it.
In the previous article, we looked at how to find ideas for your product, and I narrowed down one for me. To avoid getting stuck in an infinite loop of brainstorm and bullshit, you want to start building as soon as possible. The faster you get it out, the faster you'll see if people want to use it, how they use it and what other features they want to see you build. Without shipping, it's difficult to get any idea of what they want. There are obvious exceptions here: Apple hardly uses any focus groups or user testing, they choose to ship the very best (according to them). That's fine, but you're not Apple (yet).
While a decade ago, development time was long and took lots of planning to get right, today we can go from idea to basic product in a matter of days.
We have cheap and easy to set up servers (virtual private servers or VPS, like Linode and Digital Ocean), and platforms as a service (PaaS, like Heroku) that take out all the difficulty of setting up your own server. Languages like Ruby, JavaScript, PHP, Java and their frameworks like Ruby on Rails, Meteor, Laravel, Spring Boot, make it easy to build products by skipping the groundwork.
My point is, the speed of the development can be very fast now. And the zeitgeist of our time is transient, too. Everything moves fast now, and where in the past people would use an app for days or weeks, now you literally have seconds to make an impact, or they close/uninstall it. So you have to move fast to stay ahead. Another attribute of our zeitgeist is minimalism. Users finally accept minimal interfaces and minimal functionality, as long as an app does what it says well. There are single-purpose apps now that just do one small thing very well. Many of them have been quite successful.
The bad MVPs we're seeing recently are creating a countermovement against the lean product development trend. And that's understandable. A lean or minimum viable product doesn't mean it can be shit! It has to actually function, users have to be able to use it. Bugs are fine, but users should be able to report them instantly (like with a feedback chat box pop up). You'll also have to fix bugs fast or people will get annoyed (and you'll just grow more and more bugs). Making a minimum viable product means it has to be viable, it's not an excuse to be lazy and make something half-assed. So it's all about balance. Make something great that functions, and it can be minimal. But make sure it works!
You should use whatever tool works best for you. What tool do you already know? Use that.
What you should definitely NOT do is listen to programming hipsters on the internet telling you which language is best.
Here's a little secret: The people discussing what programming language is best are not shipping products. The people who don't care what programming language they're using are shipping products. They'll use whatever tool they need, whenever they need it.
Useful resources:
Lauren RotmanDirector of E-Commerce, Creative Bag
When building, try to build fast and minimal. Instead of learning new stuff, use the tools you already know to build your idea. Make sure your MVP actually works and is not just a landing page that doesn't do anything. Lose your perfectionism, it'll never be perfect any way. Don't outsource, build it yourself. If you can't code, use off-the-shelf tools and connect APIs together to build it. Appreciate your constraints and limitations, they can be a giant advantage vs. people with plenty of resources. Keep your costs low while building and later on. Build for the web first, you can go native mobile later. Don't build on an MVP too long, a good rule of thumb is to spend max. one month on it and launch.