Note: I wrote this in 2014, six months after launching Geocodio.

Side projects are an alluring prospect for many developers: you can have total control over a project, try new things, and reap all of the profits. No pesky product managers or dealing with other people’s code. But that doesn’t mean it’s easy. Here are a few of the lessons we’ve learned since launching Geocodio in January:

1. Take care of the the legal stuff. I can’t stress this enough, and this is number one for a reason. At a minimum, make sure you have an LLC set up and a Federal Tax ID. It’s several hundred dollars well spent and a pretty easy process in most states. Even if you’re not planning to accept payments from the start, you should make sure you’re legally protected.
2. Make sure it’s cool with your day job. Many companies have employment contracts that state that any intellectual property developed by you during your employment period is theirs, regardless of whether you develop it on company time. Even if your contract allows for side projects, it’s a good idea to let your boss know about the project (“It’s just a side project, and I don’t intend to use it as an exit strategy from this job”) and reiterate that you’re not using company time for it. For extra good will, it’s worth considering letting them use it for free (within reason). This is a side project, after all, and you want to make sure your paycheck is safe.
3. Build something you’ll use. Dogfooding is nothing new. But when you’re building a side project, it’s especially important because you’re a one- or two-person team and need to personally have all of the subject matter expertise to identify the need and build it. And, even if you don’t end up attracting many users, it’ll still be useful to you.
4. You don’t need to be single, young, and without obligations to have a side project. There’s been a lot said about how young, single males have an advantage in the tech world. But, as Justin Jackson noted earlier this year, having a family can actually be an advantage — procrastination isn’t an option when you have limited time, and when you have a family to support, you need to monetize right away. In fact, my husband and I have had four launches in the past year — two iPhone apps, a web app, and Geocodio — and all have been since having our daughter last summer. Before that, we’d only talked about ideas, and didn’t seriously start working on them until we were staring down the staggering cost of daycare.
5. Just getting to launch is success… It’s often said that ideas are useless and it’s the execution that matters, and this is absolutely true. 90% of ideas are never built, and 90% of those are never launched. Having a shipped, useable product is a huge accomplishment.
6. …but not everyone will see it that way. Unfortunately, there are still people who will expect perfection from your product and treat your project with the same critical eye they would something from a hundred-person team, or will brush it off and say “I could have built that.” At launch, Geocodio was specifically geared towards people who couldn’t afford a thousands-of-dollars yearly contract with Google or Bing but still needed a lot of geocoding, and we were upfront that our results are close (but not as good) as theirs. Yet, we still had a few people complain that it was useless because it wasn’t as good as Google. Haters always gonna hate.
7. With that said, be appreciative of feedback and use it to improve your project… For every negative person who commented on Hacker News, there were dozens more who were willing to give it a try and provide us with suggestions on how to improve it. Be open and welcoming to feature requests and improvements.
8. …but don’t end up with a camel. There’s an old joke that a camel is a horse designed by committee, and there are a lot of projects that have met the same fate. Basecamp, for example, has a wonderful philosophy that new features should be required to stand on the porch in the rain for three days before being let in. Keep tabs on the number of people who request a feature (we use Gmail folders) and then, if there are enough people who request it, we add it.
9. When you do add a new feature, email the people who requested it and ask them to be free testers. This is a not only a good way to get people to test the feature, but to curry good will among your users. Whenever we’ve released a new feature (reverse geocoding and CSV upload in particular), we’ve reached out to the people who requested that feature and asked them to spend a week or two testing it, for free. It’s a nice way to remind them of the product and show them that their needs were heard.
10. Be responsive. No, I’m not talking about design. Make a concerted effort to be available and responsive to everyone who reaches out to you about your project. Even a “Thanks, we’ll look into it” just to let them know they’ve been heard. This is nothing new, but we’ve found that Twitter is especially helpful for support requests (and is easy to respond to from your phone). It’s not always possible to respond to everyone same-day since you have a day job, but it’s important to get back to them at some point.
11. Show people how much you appreciate them. Within a few days of launching, we had several developers build libraries for Geocodio. We never expected this, and it made it so much easier for other people to use our API. As a result, we’ve made a concerted effort to show these developers how much we appreciate their help and give them early access to new features, prioritize their feature requests, and throw in other perks. It never hurts to appreciate people too much.
12. Your target users may change, and that may require product changes. When we started Geocodio, we thought our primary market would be developers who, like us, had freelance or side projects that required more daily geocodes than the free limits from the major mapping providers. Developers love REST APIs and thorough technical documentation, so that’s what we made. But as it turns out, there are a lot of non-developers and people with spreadsheets who need geocoding, and an API isn’t usually the easiest method for them. So we made a dashboard that allows people to upload a CSV, see the geocoding progress in real time, and download it from the same dashboard.
13. Not only define success, define several levels of success. You’ve probably heard many times before that you should “define success,” but it’s such a generic term that it can be hard to nail down exactly what that means. I find it helpful to define several layers of success, and to break them out for different time periods. I call them “cautious success,” “moderate success,” and “wild success,” and break them out for launch-one month, six months post-launch, and one-year post launch (and then re-evaluate). For example, for Geocodio’s first month, cautious success was defined as the service not crashing and being able to cover our server costs for the first month.
14. When it comes to growth, don’t reinvent the wheel. Growth strategies like sending out personal welcome emails to new users, using Twitter for support, and giving out free stickers aren’t revolutionary, but they work and aren’t too time consuming. Your user base will be built one person at a time, and rolling out the red carpet for each user — especially when you’re just getting started — can pay off in spades later on.