Why Side Projects?

Profitable Side Projects

This book is about creating profitable side projects. It isn’t about building the next big thing, and retiring on your millions in three years time after an acquisition by Facebook. It isn’t even about building businesses that will replace the main income of your existing job, freelance work or agency. This book is about launching a product that will make enough money to pay its way as part of your portfolio of revenue generating activities as an individual or business. A side project that is worth investing time and money into, because it shows a return. A side project that won’t be abandoned due to the need to work on more lucrative opportunities.

Side projects are about more than just the money you might make from them. Launching Perch opened up a world of opportunities to learn and develop my skills as a business person. Working with clients we were often in the position of needing to help them market products, by way of the sites and applications we developed for them. The things I learned through marketing my own product could be fed back into our suggestions to clients.

Developing your own product means that, perhaps for the first time, you are also the client, you get to make the final decisions. If you need to bring in outside help to launch or develop your product you may well quite literally become a client, and in a later chapter I’ll share with you some of the things I have learned by being on the other side of the relationship. Even if you do all of the work yourself or in house, the chance to have total control and have no-one else deciding to chip away at design decisions or limit technical choices is an exciting, and sometimes terrifying, thing.

It is possible to get many of these additional benefits of a side project with a free product, but as we will see in this book, things change when you start charging and making money. The expectations and feedback from your users will be different and, as a business, once you start to see your product as part of your total revenue your focus is very different from that toward something you just give away.

Dreaming Small is Underrated

When I talk to my peers about our journey with Perch, I often start to hear their own ideas and dreams of the product they have always wanted to build. Frequently it seems that the sticking point is that this product has already become so fully-featured, so large in their minds that they are unable to get started on it, where would they find the time? Launching something that solves such a huge problem would take a huge amount of development time, need a lot of money invested up front. Or, they can only see the end goal, the point at which the product is all they work on, they are unable to see the progression from being a freelancer or agency to being a product business because they imagine they would need to immediately switch from A to B.

It isn’t surprising that people feel this way. We’re told to “reach for the stars” and to “dream big”. The press is full of stories of entrepreneurs who have risked it all, eaten noodles for three years while sleeping under their desks and are now basking in the glory of their acquisition. Big wins; big stories make the news. The news rarely reports on the hundreds of similar desk dwelling, noodle eating hopefuls who are still clinging to a dream that is unlikely to ever materialize. The news also tends to fail to report on the many small, successful product businesses that are launched every day by people like you and I. People who can develop something small, launch it, make money from day one and develop it into a nice business. A business that is providing something of real value to its customers and enough revenue to give it longevity.

Therefore I really do believe that many decent product ideas are abandoned due to the gulf between what we believe makes for a successful product and reality. If your idea is likely to bring in $20,000 per year of revenue, that is never going to make any headlines. It is not going to be of interest to any investors. However, if you are currently a freelancer or running a small agency, what difference would an extra $20,000 a year make to your cash-flow? For many web designers that figure is going to represent the income from several projects. Success can mean many different things, and the beauty of a side project is that you get to define that success for yourself.

What defines success for your product?

When we launched Perch, back in 2009, we hoped to sell a copy per day. A copy per day at £35 (about $56 USD) would mean that Perch brought in, after deductions for payment processing and so on, around £10,000 ($16,000) per year. This was enough revenue to make the product worth continuing to develop and to ensure we could support the customers who were using it. If your product is going to require ongoing support and resources then you need to have some idea of what constitutes enough success to maintain it. How many customers and accounts would enable you to see this as a successful part of your portfolio?

Ultimately Perch surpassed our expectations, selling more than four times that goal of one license per day in its first year. However, starting small and defining success as being quite a modest thing enabled us to quickly get Perch to launch, and getting something launched as soon as possible should be your focus right now.

Getting to the Shipping Point

I expect most readers will be familiar with the Lean Startup concept of the MVP (Minimum Viable Product). It’s a term that is used to describe a small product or feature of a product that has been developed with just enough features to make it viable - to be enough that people will be willing to buy or sign up. I really like the description in John Radoff’s blog post on the subject,

“The goal of a startup is to find the sweet-spot where minimum product and viable product meet–get people to fall in love with you. Over time, you listen to your customers, make improvements and raise the bar on what viable means–making it more expensive for competitors to jump in.” - John Radoff

The funded startup may well have the luxury of being able to develop just enough of a product that people will be willing to subscribe to a free plan. If you are launching a bootstrapped product then your aim should be to ship something that people are willing to give you money for as quickly as possible. This means launching with the minimum that will make your product something people are happy to buy. Getting people to give you money is important and not just because, as a bootstrapper, you need it to continue investing in the product. Launching with something free, or running a long beta period may get you users, but won’t necessarily get you customers. While those free or beta users may give you feedback, it will be very different from the feedback you get from people who have paid for your product.

Perch launched as a paid version from the outset. Other than a few early beta testers we have never offered a free download or trial version of the software and the initial version we shipped had an incredibly tiny feature set. The core use case of Perch is to be able to drop Perch tags into your page, reload the page and then start editing content in the administration panel. That first version had image upload - content editors could upload images - but no way to resize them. It had no way to add new pages, there was no developer API and so on. All of these were things that we wanted to implement, however as soon as we got Perch to a point where we thought we could sell it, we shipped it.

Perch was developed over about four weekends, as a side project. It was profitable, from license sales, within 24 hours of launch. We’ve developed, improved and refined it over the past four years based on listening to our customers, and keeping an eye on what is happening in the web industry in general. It is now all we do as a business, it has taken well over half a million dollars in revenue, and continues to grow as a product and in numbers of customers.

Although we continue to have great success with Perch, prior to launching Perch we had another idea that didn’t turn out so well. In fact it never even launched, despite the fact we spent far more time, energy and money on it than we did on the first version of Perch. So I feel somewhat qualified to include a word of warning in this chapter.

A Cautionary Tale

It is something of a standing joke that every developer wants to build their own bug tracker, and we were no exception, coming up with an idea for a bug tracker based on the “Getting Things Done” methodology. We spent months discussing and planning the feature set, alongside our client work and even had an intern working with us on the project for an entire summer. Masses of code was written, features were tested, we even started using it internally. However we had such big plans for it that we could never get to a point where we were happy enough to ship it. Every time we started to work on it, we were dreaming up new features and worrying about various perceived defects - all before anyone outside of our company had seen it.

Ultimately we gave up on it. Our interest and energy had been sapped by endless revisions, and the product had lost all focus and momentum. We never got to see if it would have been the next big thing in bug tracking. We never benefited from seeing what people would do with it; or got to understand the features that other people will need. The longer you work on your product before customers get their hands on it, the more chance there is that you are putting time into features that no-one wants. Get to the shipping point with your product. Get it into the hands of your customers. Start making money and talking to real customers about what they want.

Minimum Viable Infrastructures

This book is less about your product and more about the infrastructure that surrounds it. However just as you can launch a product with the minimum that makes it something people will pay for, you can also launch a product with the minimum of infrastructure around it. You will need some things, but these days there are a wealth of services that seek to provide solutions to other startups. You can use these - even temporarily - to get to launch quickly and then iterate on your infrastructure as you do with your product.

Taking time to consider your infrastructure, even if you decide not to implement some elements immediately is an important step in considering what happens if you succeed. For example, and as we will discuss in later chapter, most product businesses are charging fairly small amounts either as a recurring payment or a one-off for a download. Managing all these small payments from an accounting point of view is a very different thing to dealing with the small amount of high value invoices you might be used to as an agency or freelancer. Putting in place some tools and processes to ensure these are added to your books in the correct manner will prevent a lot of pain when you come to do your end of year accounts. Thinking through that process will also help you consider whether any tax rules apply to your product, such as the VAT rules in Europe. You can check with your accountant or directly with the tax service what applies to you.

As we will consider when we talk about pricing and pricing models, your infrastructure has costs. Taking payment has a cost, third party solutions you use for support or sending out emails have a cost. Unless you have accounted for these things then you may find that the price you choose is too low by the time everyone else has been paid. As you read this book be happy to throw out all that does not apply to you, and in the things that do consider your options balancing the fact that paying for a service might get you to launch more quickly against the fact you need to keep costs down. If paying for that $29 a month service saves you a week of time and means you can start selling to customers a week earlier, it is worth it. If there are no show stoppers, it is worth it. You can always switch to something else later.

Own your customers and data

On the subject of using third party services to get to launch quickly, there is one area in which I would not compromise. Make sure that the services you are using allow you to export all of your data at any time. The exception to this would be credit card data, although some payment providers do have methods of transferring this, you probably don’t want the liability and compliance issues of storing that yourself. If you are using a third party to deliver your product ensure that you get the customer information and are able to contact these customers. If you are using a hosted help desk, ensure that you can export all the data. I would advise that you routinely export and backup data from the services that you use, just as you backup your systems.

The data that you store about customers and their interaction with your sales site and product is valuable, even if you are not in a position to analyze it as yet. Ensure that you have access to it and that you are able to export that data in a way that will be useful in the future. An export to a CSV file will at least give you something that could be opened and read in Excel or imported into another system in the future.

Small Things Can Grow

Perch is not alone in being a side project that grew over time to become a business in its own right. Starting small does not have to mean limiting yourself to a tiny product forever. What it does mean is that you can grow sustainably, using the resources you have. For example, not having a mountain of funding to throw into advertising means you are unlikely to suddenly have scaling issues causing unreliability of your SaaS application. Usage will grow over time and you can add servers or improve code and infrastructure to cope. You are unlikely to find that overnight you have a thousand new users all needing support, and no-one to help them, leading to disgruntled people complaining on Twitter.

As you will see throughout this book, there are many stories of tiny products developing into fully fledged businesses in their own right. Starting with a small thing simply means you can make that journey taking your customers along with you, rather than waiting for your giant, complex thing to be ready and perhaps finding some other solution in the meantime.

Take Action: First Steps to Launch

The aim of this book is to encourage you into action. To help with that, at the end of each chapter are a set of action points. Things that you should be thinking about or researching in order to move forward towards the launch day of your product. This chapter is no exception. I’m going to ask you to spend some time thinking about these two questions before moving on to the rest of the book. Write your thoughts down somewhere, and keep your answers in mind as you read on.

1. Imagine yourself one year on from launch. What would define a successful year one for your product?

2. What can you remove from your product feature set right now that would make it simpler and quicker to launch?