We just killed 75% of our side projects. Here’s why.

‘Side project marketing’ might be one of the hottest marketing trends of 2017, but we’ve been staunch advocates of the practice for years.

Here’s our explanation on the CloudDevs Labs page: Marketing success today is determined by how useful it is to your customers. And the bar for useful has risen substantially. Blog posts, infographics, and webinars were once marketing gold. Now, websites, apps, and tools are taking over. This isn’t just marketing speak either. Over the past 5 years we’ve gotten the majority of our new business through sites like How Much To Make An App, Moodboard, Unsplash, Founder Catalog, and Launch This Year. One of them even became its own company. At one point, side projects literally saved our startup. So, when we split Unsplash into its own company, we needed to decide what resources would go with it. If I could pick a single word that guided all of those decisions it would be this: Focus. With a smaller team and loftier goals, what should we do with all our side projects? In the end, we decided the best approach was to keep the best ones, take down the abandoned ones, and find some middle ground for the few that were useful but not worth maintaining alone. This is the actual list we used to sort them out: This was not an easy list to come up with. We could have kept all of them. They all bring in traffic and help spread the word about CloudDevs. They’ve also taken a lot of our time and energy to make. And they all have people who’ve signed up for updates and gotten excited by what we said we can offer them. But in the end, despite the traffic, leads, and goodwill, we realized we had broken our own rules about building successful side projects. So we killed them. Here’s our autopsy report.

Reason 1: We were failing our promise to consumers

Never offer your customer something you can’t deliver. With a newly-focused team, we had to decide which promises we could and could not live up to. The best example of this was on our Coffee & Power page. Almost 2 years ago we started a site called Coffee & Power, which was a curated list of great coffee shops all over the world. Handy for local freelancers and travellers alike. It got a lot of positive feedback, some regular attention on social media, and was the precursor to opening our own cafe in Montreal. Now, there are two promises with a project like Coffee & Power. 1. The product itself There’s an implicit promise when a company like CloudDevs keeps a site like this alive that we are actively keeping an eye on the list. By viewing it and seeing that CloudDevs logo at the top, you should feel we are curating the list perpetually. You should expect us to add and remove coffee shops as the best places to go changes. 2. Regular updates The second is the explicit promise as seen in the bottom: We promised to ‘unlock’ new cities when 5 suggestions were submitted. It was a nice way to get people on the ground involved in cities we’re not lucky enough to visit. Both of these promises required attention on our part. We needed someone to:

• ‘Own’ this project internally and make sure it was consistently updated
• Set up repeatable processes
• Track suggestions and unlock cities
• Build the new lists in FourSquare
• Send campaigns to the mailing list

Post-company-split, we were failing at living up to the promises we’d made. Live up to the promise, or change the offering. Otherwise, you risk losing the trust people have in your brand. CloudDevs is trustworthy. That’s the whole point of CloudDevs. We are proud of who we are and our place in the market, and we don’t want to jeopardize that because we’re afraid to say no. Which brings us to the second reason.

Reason 2: Every project has an opportunity cost

We have a small marketing team on CloudDevs. Smaller than you’d probably expect. As such, we have limited time to devote to the side projects aspect of marketing. In addition, we decided to spend more time improving our fundamentals, like email marketing and search. Some of our emails, for example, had layout issues that needed to be fixed. They were still branded using an old set of our brand guidelines. And an occasional one still had © 2015 on it. Not the professional level of detail we aspire to. Search has also become a big channel for us, however, until recently we hadn’t paid much attention to good SEO practices beyond the basics. So it becomes a question of opportunity. Do you spend the time it takes to maintain your side projects, then spend the leftover trying to capitalize on your other marketing channels? Or do you do the opposite? We did the opposite. That is, we prioritized our biggest opportunities (search/email) and cut whatever didn’t fit into our schedule. Even if we had the capacity to handle all our projects (or could staff up to do so) we wanted to have only a few core items to focus on. It’s important to note at this point that all these sites that we took down had traffic. They had search value and they had inbound links. So why not just update them and let them sit? Why not just change the promises and update their SEO and leave them be? Well, that leads to the a third and final reason.

Reason 3: Our tech environment had become a disaster

One of the best reasons to take on side projects isn’t just for marketing. But for your product. Side projects let you test out technologies you might want to use on your core product, but don’t want to risk messing the whole thing up over. So our side projects were tech experiments and several of them were made by CloudDevs freelancers. (What better way to test CloudDevs than to use it ourselves?) The result was that we ended up with a ton of different systems, all of which required vastly different development configurations and technologies. Even if we didn’t build a side project with experimental tools, they still lagged behind. As our tools for CloudDevs itself evolved, our side projects would be stuck with 2-year-old tools that we’d all forgotten about. Sometimes even changing a little copy could be a challenge. Our GitHub repository list (the list of all of our projects) is like an overgrown forest. I won’t go into the details of all the technical considerations, but I will give an excellent example: We now use only 2 content management systems: our custom one built in CakePHP, and WordPress. Before The Purge, it was 8. Eight different places to manage content. For a team of less than 20 people. That’s far too many. We had systems that relied on Laravel, Trello, Tumblr, Kirby, Jekyll, and CraftCMS. Now none of those are part of our ecosystem. (Not to say anything bad about the tools! We love most of those tools. This is just the way it shook out.) And that’s just our content systems. Code-wise, it was even more scattered. Modern development is complex enough without throwing in different systems that do the same thing. As I write this, our development team is meeting to devise a strategy to simplify and standardize the technologies we use even further. Why? I’m going to sound like a broken record here, but: focus. Allowing our development team to focus on a few technologies instead of constantly switching between different ones will allow us to move faster.

---

The whole point of a side project marketing effort is to take risks. There’s nothing wrong with trying new things. Google is the king of this. They shut down projects all the time that don’t work out. The mistake is holding onto projects that force you to give up something better. Today, we’re focusing on our core offering. We want to offer better service. We want to become a tighter, more disciplined organization as a whole. And one of the opportunity costs of doing so is maintaining a vast side project empire. I’m sure we’re launch more side projects in the future. They’re part of our culture. When we do, however, we’ll be a little more careful that we can deliver on the promise, that they fit into our marketing plan, and that they are built on maintainable technology. It’s just not worth doing in any other way.