About a year ago, I wrote a post explaining a major new project that we would be starting. I didn't say so at the time, but that project involved a complete rewrite of our CRM software along with some major product changes. My silence on the topic since then has probably made it obvious that the project was abandoned. That may sound like a failure, but it was actually a great move for our business. Here's the story of the project that wasn't meant to be:
The background
Leading up to the Spring of 2012, Less Annoying CRM was doing well. About six months earlier we had hired our first employee to handle customer service, and we were profitable enough that Bracken and I (the co-founders/developers) were finally able to stop working side jobs so we could focus on LACRM full time. Even still, we didn't feel like we were growing the way we would need to in order to have the type of success we were hoping for. We thought that the conservative nature of our product was to blame. The CRM market is incredibly crowded, and while we were really proud of our software, it wasn't particularly innovative. It was just like all of the other CRMs, but just a little bit better. It was a rock solid lifestyle business, but we were concerned that no amount of iteration would ever result in a truly disruptive product.
We started daydreaming about what software we would build if we really wanted to disrupt the industry. After a few weeks of brainstorming, designing mockups, and talking to everyone we knew, we had come up with the perfect product. It would solve all of the same problems as LACRM, plus many others, and the overall user experience would actually be even simpler than LACRM was at the time. I even showed it to a few current customers, and they went absolutely crazy for it. Since we were already making enough recurring revenue to pay the bills, we figured that it would be worth the risk of trying to build it. This would mean putting the development of the current version of LACRM on hold and starting writing the software again from scratch.
So we started the new project. We decided to try Meteor: a brand new (and still in Beta) system for building web apps. We also planned on switching to MongoDB. So we got our development environment set up, and started learning these new technologies.
Let's pause right here. At this point in the story, we had already made a ton of major mistakes. Looking back, it's clear that if we had stubbornly continue this project to its completion, we would have wasted over a year on a doomed project. We probably never would have finished the project (any number of things could have completely stalled us) and if we did finish, the resulting product probably wouldn't have been nearly as well received by our customers as we hoped. Worst of all, our existing product which had hundreds of customers that loved it would have stagnated, and our customers would have lost faith in our ability to innovate.
But we're not stupid. If we were headed toward such a colossal boondoggle, there must have been a reason.
Why code rewrites are so appealing to programmers
We certainly aren't the only software company to be tempted by a complete code rewrite. 37Signals (the prototype for the type of company we want to be) launched a completely new version of their product just before we decided to do it ourselves. Every team I've ever worked on has toyed with the idea at one time or another. Something about getting to rewrite your code just sounds...fun! Here are just a few of the ways we (programmers) justify projects like these:
- When we originally started the company, we didn't truly understand what the product would turn into. We've learned so much about how the product should actually work, that we should start over, this time with the correct vision from the very beginning.
- Since starting the project, technology has advanced. If we do a rewrite we can use all this cool new tech. Wouldn't it be cool to use the new NoSQL database and real-time front-end MVC javascript framework everyone is talking about on Hacker News?
- In the early days, we were in a hurry to launch, so we cut some corners. Let's go back and do it right. This time we'll write clean code, we'll actually follow our coding standards, we'll make sure everything is scalable, we'll comment our code, and we'll be better about unit testing.
- Our code is so sub-optimal right now that it will actually be faster to do a complete rewrite than add features to the existing code base.
These all sound like good reasons in the head of a programmer, and yet rewrites are almost always mistakes. A fun tech project does not always result in a win for the business, and if you're thinking clearly, the business side of your brain should be able to call out the problems with these rationalizations.
Why rewrites are normally a bad idea
I'm sure that there have been plenty of successful rewrites in the history of software (I believe the 37Signals one went quite well) but it can be a major mistake to let nerdy tech enthusiasm dictate such a huge part of your company's strategy. Keep in mind, this is coming from a nerdy tech guy. Here are just a few of the problems with the "a rewrite will solve everything" approach.
- Projects always take longer than you expect. Always. I normally find that I spend more time on the "polish" part of a project (testing, bug fixes, etc.) than I do on the actual project itself. The bigger the project, the more likely it is to run over. The chances of delays with a major rewrite are much larger than with a series of iterative improvements, and the consequences are much more severe.
- At a startup, code is always messy. It's supposed to be messy. If you have a perfectly clean, organized code base, that means that you (a) misused your time and/or (b) have too rigid of a framework that doesn't suit the always-changing needs of a startup. Maybe at a giant company with a relatively static product it makes sense to try to write perfect code, but that's just a silly pipe dream at a startup. You can try rewriting your code, but a year from now it will probably be just as messy as your current code is.
- You'll fix old mistakes, and make a bunch of new ones. Thinking that you can have the perfect code framework is just wrong. If it's so easy to write mistake-free software, then why didn't you do it the first time. It's not because you were in a rush, it's because no one is capable of writing perfect code.
- The cutting edge technology of today won't be the cutting edge technology of tomorrow. It might not even be supported tomorrow. Because of how quickly technology changes, there's no point in trying to always be on the cutting edge. You're better off picking established technologies that have strong community support so you know they aren't going anywhere. This is too important of a decision to worry about what's cool.
- As is the case with any project, code rewrites can fail. There's a very real chance that you'll spend the next 6-12 months on the rewrite only to abandon it because it's not working out, you exceed your budget, the existing product is dying from neglect, or any number of other reasons. The bigger the project, the more likely it is to fail, and the more costly failure will be.
- There are probably some relatively minor changes you could make to your existing product that your customers would love. If you do a rewrite, you have to put your progress on hold for a long time. You'd basically be ignoring all of the easy wins in an attempt to capture a likely-to-fail hard win.
These problems all have one thing in common: the rewrite doesn't contribute any value to your customers. The point of a startup isn't to have fun playing around with cool technology. It's not even to make a great product. The goal is to improve the lives of your customers, and it's incredibly unlikely that rewriting your code will further that goal. They don't care what database you use, or whether you're using server-side javascript. They just care how well you solve their problems and there are almost certainly better uses of your time than rewriting the entire code base.
Just to be clear, I'm not arguing that you should ignore the state of your code, or that you should never experiment with new technology. But just like any other aspect of a startup, gradual, iterative improvement is almost always preferable to a major, risky project. Instead of rewriting your whole project, why not just gradually re-factor your existing code? Instead of switching your entire project to some hot new technology all at once, just move the features that really need the new tech over, and gradually migrate everything else if the initial project is a success.
So...what happened?
I have no doubt that if we had continued our rewrite project, we would have realized it was a mistake and abandoned it. It might have taken several months for that to happen, and luckily, outside forces intervened and taught us that lesson less than a month after we got started.
In May of 2012, we added more than twice as many new subscribers as we had a month earlier, and our pipeline of new trials users looked stronger than it ever had before. I'm still not sure why this happened, but it doesn't matter. This random stroke of luck caused us to question our assumption that the existing LACRM product could only be a modest success. We were talking to tons of people who absolutely loved the product, and all of the feedback we received suggested that we were just a few improvements away from having something truly special. Maybe a boring CRM can be disruptive after all.
So we decided to stop the code rewrite and get back to what was already working. We quickly planned some small but important improvements to the existing product including a redesign that solved some major UI issues, a much improved onboarding experience, Google Contact syncing, and a new way to browse contacts that solved one of the major complaints from our customers.
These changes took a few months (except for Google Contact sync, that project had already been in the works for quite a while) and it immediately boosted our signups even more and thrilled our existing customers.
Silver linings
It may sounds like we wasted a bunch of time planning an entirely new product and starting a code rewrite, but it wasn't a complete waste. Brainstorming for the new project actually resulted in some really cool ideas that we might have never come up with otherwise. Two of the major improvements I mentioned above (the redesign and improved contact browsing) came directly from the mockups we made for the new product. As a matter of fact, those were probably the most important improvements we had planned, and instead of taking a year to build, they made it into Less Annoying CRM in a few months.
I actually think that we're much better off for having taken the time to design the perfect product, it was just silly it was to plan on building that product right away. Believe it or not, I still believe that LACRM will end up looking and working a lot like the grand vision we had planned, but we'll get there gradually over time. So even if now is not the time to swing for home runs, it still might be a good idea to let yourself daydream about the future as a way of coming up with ideas for the present.
Final takeaway
At the time of this writing, we have 2.5 times as many customers as we did a year ago (which was around when the rewrite project was going on). We've added two new employees and have two more joining soon. We're still small, but we're growing faster than we ever expected, and we managed to do this all in roughly the amount of time it would have taken to finish the code rewrite (assuming we could finish it at all).
So the major takeaway for me is this: when you get excited about a new project, don't just think about all of the benefits. Also consider the opportunity cost. Would a rewrite be fun? Yes. Would the new product we designed be amazing for our customers? Yes. But just because there would have been some benefits to it doesn't mean that those benefits even come close to outweighing the benefits of other options. It's boring, but iterative improvement is almost always going to result in the best outcome for a startup. Luckily, we learned this without paying too high a price, and hopefully this blog post helps you do the same.
Sign up to receive updates in your inbox