This post originally appeared on Ascent
The story is a familiar one.
An excellent idea, simple but valuable. A fresh codebase, like a world of possibilities. A side project is born. A weekend of delivered pizza and whirlwind coding lays the foundation of something wonderful. But then the novelty fades. Productivity slows. Eventually, between work and family, progress all but halts. Momentum is lost. But then you have a new idea. This is the one. The cycle repeats.
Momentum is everything to side projects. Keeping it can be hard. The trick is two fold: avoid things that lower momentum and keep your scope small enough that it completes before momentum runs out.
I have built many side projects. Most have never launched. But for each failure to launch, at least one of the mistakes in this article is the cause. Over the years, i've learned what to avoid.
My newest endeavor, detextion.io, was built atop these lessons and has grown to be my most successful project. Its success is due in large part to not repeating my past mistakes. I hope that they can help others avoid the same traps I spent years discovering the hard was.
Easily the biggest roadblock to launching a side project is starting with a stack you are not familiar with. While side projects are the correct place to play with new techs, projects you intend to actually launch are not. When you start a side project, ask yourself if this project is for experimentation or launching. If you pick launching, pick a stack you know. Period.
The reason for this hard and fast rule is all about momentum. Nothing kills momentum quite like those moments when you think to yourself "how do I do this? it would take me 2 lines in...". Don't fall into that trap. I firmly believe every time you have to google a code question, you are a little less likely to complete that side project.
As soon as you pick your stack and initialize it, release it. Yes. Seriously.
Momentum is rarely as strong as when you are starting a project. This means it is a great time to get this necessary evil out of the way. The last thing you want is to have to start a release process 3 weeks into a project only to find you have production specific issues. Don't play that game.
Pick where you want to release to and get that out of the way early. Wait too long and it just isn't going to happen. Just as we selected a familiar stack, this is also a good time to select a hosting environment you are familiar with. If heroku has treated you well in the past, go with that. If you host your own server, bully to you and host it there. Wherever you choose, release it about as soon as you initialize a project and database.
Not adding buy buttons to my projects is the single biggest failure of my professional career. While many of these points are about avoiding momentum losses, adding a buy button is a huge momentum boost.
Integrate Stripe. It will require a EIN Number. It takes all of 5 minutes to get it via an online form. A rare example of government efficiency. A beacon of hope in a swamp of... I digress.
The day you are able to run a test checkout and see the revenue graph jump up is a great day. The mere possibility of earning money from a site you build is a powerful driver that is too often ignored. Do not deny yourself this boost.
Furthermore, side projects need not be charity labor. Your time is worth more than you are being paid in your normal job. That said, your side projects ought to at least have the capability of collecting money.
So build a buy button. I'd argue you should build it before even adding the core feature(s) of your site.
I find coders go through waves of productivity. We tend to associate those waves with moments of inspiration. A more accurate statement would be that our thought process shifts over time those inspiring moments are when it shifts to the mode we are trying to work in.
There are 4 distinct types on thinking in building a project:
When you are working on a side project, you do so in short bursts. Learn to recognize where you are mentally when you start a work session. When you do, allow yourself to work in your current area of genius.
Not only will the regular context swaps keep you from feeling like things are dragging on but it is also a more efficient use of your time.
When you have one of those early creative moments, start off by writing down some basic descriptions of your product. What problem does it solve? Who is it for? Why is it a joy to use?
Reason being, side projects, practically by definition, rely more on first impressions and self-service than traditional sales efforts. To facilitate this, you will need a marketing page that clearly and concisely presents your product.
I place emphasis on "concisely" because it is a challenge. This is why I suggest writing these blocks of text early, even if they are presented with a single line of CSS.
If you have some draft copy written, you will find yourself returning to it as your own understanding of the project grows. These revisions often involve little effort but pay big rewards in the final product. But it isn't possible without an early draft of your marketing copy, so scribble some ideas down early.
And just like above, ignore the CSS until you are inspired. Trying to style the font page to a side product when you aren't feeling particularly artsy is a great way to frustrate yourself to hell and back.
Ok, real talk for a moment. We wranglers of the 1's and 0's tend to suck at this. We are either too introverted or weary or overly confident to ask for real feedback about our projects. But if there is one thing I have learned, it is that there should be no ego when building products.
The fact of the matter is every product is wrong until it is solving problems for a lot of people. Until then it is either missing the mark or isn't done yet or isn't being shown to the right people.
Once you have a working version of your project it is time to find out what is wrong with it. Start with friends and coworkers. Move on to prospective customers. Make people sign up and read your marketing. Ask them to be ruthless in their answers to you. While praise is encouraging, our product doesn't get any better because we are sitting atop our high horse. Critiques are what we need now.
Personally, I list out everyone's feedback in bullet points. Trends will emerge. People will be confused about a feature or label. People will wonder what some sentence on your marketing pages means. They will get stuck. These stumbling points should be your highest priority changes. You are better off having an under-featured product people understand than a fully featured one that confuses them.
Finally, ship it.
In truth this is the single most important step. Everything else here is a way to achieve this end. So did you skip some of the above? Who cares. Ship it. Do you still have a list of features you would like to add but don't absolutely need? Ship it. Are there some style issues on IE9 that one person you asked for advice from told you about? Ship it.
As developers we have this strange illusion surrounding our personal projects. We feel that releasing imperfect projects would diminish our reputation, or some such nonsense. Let go of those inhibitions.
The sense of accomplishment that comes with releasing a side project to the world is one worth experiencing. The lessons you learn along the way about scope, refinement, feature cutting and product presentation are invaluable to companies you are and will work for.
The old adage is that invention is 10% inspiration and 90% perspiration. Many developers will have the inspiration about a great product. Few take the steps to see that idea to fruition and reap the benefits that come from it. But they are real and worth it.
So take your idea and get it rolling. Build some of this momentum we have been talking about. The finish line could be only weeks away.
tl;dr: Side projects are notoriously hard to finish. These are the best ways to complete and launch them.