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.
Pick a familiar stack
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.
Release before you write code
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.
Build a buy button
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.
Embrace moments of genius
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:
- Feature building (Problem solving)
- Styling and copy writing (Creative presentation)
- Validations and bug fixes (Mundane tasks)
- Manual testing (Critical thinking)
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.
Clearly describe your product
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.
Get feedback
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.
Ship it
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.
Top comments (9)
... so true with regards to the stack question. Time to market is crucial for pet projects as well, either you can get the main part of your application done within 48 hours or it's hard to keep the motivation high during normal working days. Cut features for the first version if it helps. Good read though š¤
Your suggestion on picking a familiar stack holds so much truth! Whenever I think about a new project, there's always the novel idea of Trying Something New. But you're totally right -- if this is a project you actually intend to launch, picking a stack you're familiar with can only increase your momentum and productivity. Really appreciated reading this -- will help me remember for next time!
Just a comment on sticking with a familiar stack. I think there are projects that you obviously know that your current stack cannot solve. So it's better to build with the unfamiliar tech stack but agreed, if it's a product sticking to a familiar stack when it can solve the problem will help keep the momentum. Nice Post!
Yeah, I'm torn on this part of the advice. I think it cuts both ways in terms of getting the project done. Some new technologies are easier to pick up than others, so it's hard to paint that with broad strokes. The new tech is also sometimes the motivation for the project, and that cannot be discounted.
Though initial motivation by a new shiny toy that falls off is probably a big reason for the failure to launch idea in the first place.
There has to be a clear motivation for the project.
If the motivation is to use the new hotness than focus the project on that. Then setup the project in a way to properly gain familiarity with the new tech.
Whereas if motivation is a hot new idea and you want to see it to market, it is typically safer to use a tried and true stack and gain the joy of the wins of seeing the project advance.
My would recommend not tying a single project together with these two disparate goals, unless you plan on leaving one by the way side to see the other succeed.
Great advice, especially 'Pick a familiar stack'. I just had to learn React for my current side project, and while it's been an amazing journey putting the React pieces together, I've lost all momentum and interest the the actual project haha.
I literally have like 6 side projects that are 90% complete, I just need the motivation to finish them. They get far enough along that they solve my current problem, then they sit until I need them again for something. If someone besides myself was interested in using them, that would be all it would take to motivate me to polish one of them. I just need to know if someone would actually use them.
Curiously, even my most starred project, github.com/wmhilton/download-with-... has >150 stars but hasn't received any feedback in the form of issues or pull requests. I don't know what the "next step" is. I think I've made some great stuff but short of Twitter (which I do try to use - that's how I find most dev.to articles) I don't know how to get the word out.
Brilliant. Great sum up. Thank you. I shall be getting some of my side projects to day light again using these advices.
What a great post - inspires me to start a project and use it as a roadmap.