In this post, I’m going to teach you how to ship your side projects.
How to turn them into a potential business. Keyword: potential. There are no promises here.
I can’t turn water into wine, people. 😉
Now, back to shipping side projects …
It’s easy once you realize how difficult it is.
Yeah, that sounds bass-ackwards. 🤔
I’m serious, though. It is easy once you see that the difficult thing is looking you in the mirror.
Yes, you’re getting in your own way, and you don’t even know it.
I’ve been shipping side projects for over 20 years. Some did well, most failed. It’s how it goes. You have to roll with the punches here.
What is a side project?
A side project could be something as simple as:
- A weekly newsletter (like this one)
- A weekly blog post
- A mobile app you wrote
- A web app you wrote
- A tool you created
- An open-source project you created
- A script you wrote
- A framework you developed
- A physical book you wrote
- An ebook you wrote
- A video
- A tutorial
- …
You get it. A side project could be anything that you want.
For the sake of this post, I’m going to stick with a software product, though.
It could be a mobile app or web app, or even a desktop tool.
Nuff fluff: Let’s get to it.
Tip 1: Realize That You’re Going to Fail
The sooner you realize that your chances of success are low, the faster you can ship it.
You’re thinking: “What? Huh?”
Once you embrace this thought … you have nothing to lose.
If you don’t ship your side-project, you’re in no better spot than you are now. The only difference is that you have a bunch of dead code in a folder on your drive somewhere (your project).
If it sits on your drive, it’s worth nothing.
Yeah, blah blah blah, I know … you learned something from it, so it’s not entirely useless. I get it …
That’s not why you’re still reading this post, though.
You want to learn how to ship it. Right? Right.
Embrace the truth that most likely, this project will fail, but you don’t know for certain until you try.
I want you to know that I’m not trying to be a downer here. I’m trying to help you realize that this is the reality of shipping side projects.
So… ship it already.
Tip 2: Forget about monetizing it for now
You most likely fret over this like crazy.
I know I have more times than I’d like to admit. Hell, I still do it.
You get stuck in an analysis paralysis loop of the following questions:
- “How can I make money off of this?”
- “Will the user pay for it?”
- “Should this be a one-time payment or monthly subscription?”
- “Can I monetize this with ads?”
- “Can I find enough 43-year-old moms who drive Ford minivans built between the years of 2008-2012 that will buy my custom rear-facing baby dashcam mount?”
First of all. Forget ads. That ship has sailed.
Storytime – back in 2008, I had 4.5 million app installs of one of my side project apps, and I was making $60-$100 a day. Things aren’t like that anymore.
Yes, that’s good money for a side project, but that didn’t last long. That got shut down soon after the ad rates dropped.
Ok, so ads are out … unless you really do like living off of Ramen from the dollar store. So … what about the other options?
If you don’t have a solid plan out of the gate, ignore pricing right now and ship it.
This concept cemented one day after I heard Josh Pigford talk about this on one of his podcasts.
The TLDR is this – if you have a side project – ship it and get it out there. If it’s popular, then figure out how to monetize it. There will often be a clear path on how to monetize. If not, then run it for a while to see if you can identify a monetization method or shut it down.
In other words, if you’re having a hard time deciding how to monetize your side project – don’t. Ship it and see if the market likes it first. If there is a positive response, then think about it and adjust, but don’t let it distract you from shipping.
Tip 3: Ship it before its ready
You had to know this one was coming.
This is age-old advice that I still adhere to.
As the saying goes, “If you’re not embarrassed by what you shipped, you shipped too late.“
Why would you do this?
To see if there is any interest in your project.
Consider these scenarios:
- A) You ship early and learn that the market did not respond to your project. No one uses it. Ok, no harm – no foul. You cut your losses and move on.
- B) You ship early and find out people like it. You accept their feedback and improve the product. Awesome.
- C) You don’t ship until it’s perfect. You ship it and realize that your assumptions about the market were wrong. No one uses it, or no one understands it because of many incorrect assumptions made. You realize you wasted a tremendous amount of time.
Most everyone defaults to scenario C. They wait until it’s perfect to ship something.
Stop it. Ship it now.
Your terms and conditions weren’t done? Ship it.
Your privacy policy isn’t done yet? Ship it.
Your monthly billing isn’t done yet? Ship it.
Wait, what? Billing isn’t done … and ship it?
Yes. Ship it.
There are many companies that have shipped without functioning billing software. They wanted to get it into the public quick. These companies had another 4 weeks to wrap up the billing stuff while the users gave other valuable feedback.
Contact page isn’t done? No problem. Use a form like TypeForm. Ship it.
You get the point. Ship it when you’re still somewhat embarrassed by it, and then refine it.
Tip 4: Don’t attach your emotions to your project
I cant’ tell you how many times I’ve done this.
This is when your project is YOU. You and your project are one. It’s like a child to you.
Bad mistake.
You’re setting yourself up for some upset.
Ask me how I know.
When you attach your emotions to your project, you will make emotional decisions. Emotional decisions are usually not great ones. Furthermore, they’re often slow.
This could be anything from pricing decisions to feature decisions to support responses. Anything for that matter.
When (not if) users criticize your project, it will sting and often feel like a direct attack. That’s not their intention, but if an emotion is at play, it can feel like an attack.
This makes it hard for you to detach and do the work necessary to improve your project once it’s shipped.
Tip 5: Treat it as a learning experience
This is tip #1’s cousin.
You already know that your project has a high chance of failure. You’re not upset about it because you’re putting it out there to see if it gets any traction.
Another way to look at this is that what you’re doing now is a learning experience.
I recently did this with a project called “Gifstagram.” It was the easiest way to convert any gif into a loop-able MP4 file that would be post-able on Instagram.
I didn’t have any clue if anyone would pay a cent for it, but I knew that I used it and that it could be of use to others. I also wanted to know how to use Amazon AWS Lambda functions, and this was a perfect opportunity to learn how to use them. So that’s what I did … I created the entire web app on AWS with AWS Lambda, SES, API Gateway, Aurora, and S3.
I treated it as a learning experience to say I was able to ship a project that used all these technologies.
Let me tell you something … WOW, I learned a ton on that small project.
I recently shut that project down. It was not getting used that much, and there was no clear path to monetization.
The learning opportunity was worth its weight in gold, though. Treat your side projects the same way and you always stand to gain something from it.
Tip 6: Realize whether your side project is a vitamin, painkiller, or candy
Twizzler? Runts? Skittles? I used to eat the crap out of those.
My dentist loved me because I paid him so much money.
Ok, I digress…
Your product is “Candy” if … it’s something a user would like to have and makes their life more enjoyable, but it’s not necessary.
Your product is a “Vitamin” if … it’s something that the user should use but can do without if need be.
Your product is a “Pain Killer” if … it’s something that the user wants and needs right now to solve a very immediate problem.
Which category do you think you want your product to be in?
Pain killer.
Why?
Think of it this way: You’ve got a toothache.
What do you want? Candy? A vitamin? or a Pain Killer?
You want the pain killer.
You want the problem to go away.
If your product makes a problem go away – it’s a pain killer.
If your product makes their problem less as bad, it’s a vitamin.
If your product makes their life more joyful in some way, it’s candy.
Why are these all-important?
It’s important because it will help you plan on how to sustain the project over the long term. Will it be something you can monetize, or is this a goodwill project? This helps frame the project and its potential trajectory in the market.
Think of it this way – pain killers do better than vitamins, and vitamins do better than candy. They can all work, but where do you want to spend your time? Personally, I prefer to work on painkillers.
Tip 7: Have an exit plan
In the previous tips, you learned that you can use shipping a side project as a learning experience. This is great, but when do you pull the plug on your shipped project? Or should you?
To know that, you need an exit plan.
- This could be monetizing your project by a certain date.
- It could be getting some maintainers to help you with your open source project by a certain date.
- This could be shutting it down if certain metrics are not met by a certain date.
- It could be selling your side project if you lose interest in it by a certain date.
Notice everything is date-oriented. Nothing should be perpetual. If it is, it will take up mental cycles in the background of your head. This will eat away at your personal processing power for other projects that you have.
If you plan on selling it, you can sell on an app marketplace or website marketplace. No, you’re not going to get 15x of your time you put into it. You might get a couple thousand, or if you have a lot of users but no monetization, you might get more. Don’t expect to get rich, though. See it as a nice bonus and a responsibility you no longer have to tend to.
It’s important to know that you don’t have to love your side project forever. You will outgrow it.
If you get tired of your side project, have a plan for what to do with it. Shut it down. Sell it. Deprecate it if it’s an open-source library. Do something, but don’t let it sit around. It will take up precious mental cycles.
The Final Word
Ship it early. Get feedback quickly. Don’t wait for it to be perfect. It never will be.
PS: By the way, using this exact method I recently re-launched Android Jobs (a Job board for Android professionals). It’s not perfect. In fact, there’s a bunch of stuff that’s simply NOT done yet on it. You know what though, many companies are using it already. Companies like Instacart, Capital One, Bumble, Snapchat, Pandora, Twilio, Vizio … the list can go on and on. Long story short – your product doesn’t have to be perfect to provide value. Just ship it.