A couple of months ago I’ve shipped the private beta of Dockbit, MVP if you will. The first version of Dockbit took me about 4 months to build. I invited some of my friends to try it out and nearly all got amazed how polished it was. They loved how it looks, how it feels and how easy it was to use.
No, I am not a ninja coder, and I admit 4 months does not sound like a short time to build something awesome nowadays. However, I am still shocked by how many developers waste time on things that do not matter when starting a new venture. So, I wanted to share the practices that helped me ship Dockbit faster, and perhaps you will find them useful when building your next thing.
Don’t treat it as a “side project”
I guess, many of us developers, have a folder on the drive or a repository in GitHub with an archived project. I counted mine and found almost 20 side projects in all kinds of categories: mobile apps, social networking, marketplaces, real estate, etc. They could’ve been the unicorns of today's age, but in reality, they were just the “side projects”.
The “side project” is something that you hack with the latest trendy framework, where you’re testing out new library mentioned in the conference you attended earlier this year, or the bits you squeeze out of yourself after a long working day.
Don’t get me wrong, side projects are awesome. I love them and without them, I wouldn’t have the coding skills I have today. Side projects help us improve our skills, learn new things and sometimes they even turn into great products.
However, to me, a “side project” is something of a low priority; after work, learning, fitness, guitar practice, etc. I think the low priority of a side project is one of the biggest reasons we are taking a longer time to ship. If we changed our attitude and stopped treating our venture as a “side project”, but instead made it a higher priority, then I believe the time to get something meaningful out would have radically decreased. Remember “The Social Network”, when the main character ignored everything around him to get the Facebook out? So, instead of treating your product as a “side project”, make it as your “primary project”, and you will be surprised how things will roll on.
Don’t study competitors
I remember every time I built something, people would send me links to similar products on the Web. I would then spend days studying competitors, testing them out, and even copying features over to my product.
More recently, I realized that studying competitors is another major slowdown in getting your product out. There are several problems in studying your competitors at the early stages of the product, but perhaps the most common one is the risk to drift away from your original ideas.
You see, when we evaluate the features of our competitors, we tend to overestimate their importance. It’s because we’re not fully (yet) understanding the problem we’re solving. We haven’t yet learned enough of our users to know exactly that the features we want to replicate are actually useful. It’s not uncommon for the product to take a completely different course than of your competitors, so those early things you put into your product are what make up its contrast and first impression.
Don’t worry about tech stack
I always considered myself an early adopter who is ready to try out new tools, languages, and frameworks. However, as with side projects, we have to be very clear: are we trying to acquire new technical skills, or we want to ship the product and learn about our users.
Sure, you do have to care about the quality of your code, otherwise, you’ll accumulate a huge technical debt and won’t be able to experiment with new features quickly.
Pick the tools you’re most comfortable with to get the job done, and the job is to ship and validate your product ideas. Don’t worry if it won’t scale, or if it’s monolith, or if it’s not immutable, or if it doesn’t align with the latest trends. You need to be fast at throwing away features that don’t work, bringing in new ones and running all sorts of experiments. I am sure you will rewrite it a few times more. So, don’t follow the rabbit hole and just forget (for now) about that sexy, unfamiliar, not yet widely adopted tech stack and stick to your “super power” tools.
Don’t be afraid to launch
This is probably the most dangerous of all and I like to call it the “prelaunch syndrome”. It’s that time of the project when you’ve finished everything you planned but just can’t hit the big red button. You know it when you start polishing negligible things, adding unnecessary features (usually after studying your competitors), and have those doubts that all you’ve built is shit nobody will ever use. I’ve seen a lot of projects that never went live; sadly, it happens to many of us.
What usually works for me, is re-emphasizing the reasons I’ve started the venture in the first place. I like to think about my initial motivations and ambitions for the product. It’s important to remember that most of the features you’ve built will vanish anyway. They will transform into more valuable ones and only by shipping them we can learn how to get further.
So, change your attitude, pick the right tools, scratch your own itch and hit that red button. Best of luck!