October 06, 2009
We’ve been deleting a lot of code from Scout. We’re ripping out major infrastructure, and in doing so, pulling the plug on functionality which, just six months ago, we believed would be crucial to our business. Most importantly, we’re simplifying the most complex, error-prone, and poorly-performing parts of the application. At the same time, our revenue and sales pipeline is growing at a faster rate.
How did this happen? How did we get to a place where we can remove code and functionality and see our business will grow because of it?
As they say, “mistakes were made.” You don’t get the satisfaction of throwing out a bunch of cruft and performance-degrading features without having gone through the pain of:
So yes, mistakes were made. But also, lessons were learned.
When you have a small team, complexity is a killer. But no-one sets out to make their product complex, right? That’s the irony: we grappled with heinous complexity in the name of simplicity—simplicity for the end user. It turns out that simplicity and elegance for the end user can mean some awfully complicated stuff behind the scenes to make it work.
In our case, the move from flat data to nested data was the killer.
Here’s the culprit:
We envisioned a very versatile data store and alerting system in which a broad variety of data could be stored, analyzed and reported on. This wasn’t a pipe dream or an abstract feature wish—it had immediate application to the kind of Ruby on Rails application reporting we were building. We came up with a sweet way of storing the nested data and abstracting away most of complexities of dealing all kinds of data.
However, the load on our database was far more than we envisioned. The performance problems that resulted from this dominated our efforts for the coming months. We upped our hardware budget. We fought the fires, and yes, we made it work.
But, we made it work with very little headroom. We were already spending more than we wanted to on hardware, and we didn’t have room to grow. The database operations on the nested data were just taking too much processing power. From a business perspective, these problems went from annoying to crippling. When the service is slow, you have to address it ASAP. That takes time and focus away from sales and business development, so it’s a double hit. We ended up spending nearly all our effort during the period after launch keeping that elegant and sophisticated system running.
The ongoing cost of complexity is higher than you think. And it’s easy for complexity to sneak in through the back door in the guise of its nemesis, simplicity. Complexity is sneaky that way. Don’t be fooled.
And more to the point, you can’t sell them if you have to spend all your time hand-holding an overloaded database. After a few months of our Cool New Features being live, we had certainly signed up some customers because of them. Not as many as we wanted to however. There are two reasons for this:
If you’re running a web application and the majority of your work is spent delivering the service you advertised to your customers, you’re probably in bad shape. A good rule of thumb for paid web apps: 1 out of every 100 visitors will become a paying customer. With almost 1/2 of all web applications attracting less than 1,000 visitors per/month, it’s reasonable to expect just 10 paid signups per-month. You need to do more than just deliver the web app to make a living.
It’s a huge net-negative to build something so resource-intensive that you don’t have time to sell it. You’re much better off spending more time selling a less expansive product.