We Just Undid Three Months of Dev work. Here's What We Learned.
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:
- Building those features in the first place.
- Fighting the performance problems for a few months before you realize its all untenable and come up with alternatives.
So yes, mistakes were made. But also, lessons were learned.
Lesson #1: You will underestimate the ongoing cost of complexity in your product
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 takeaway
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.
Lesson #2: Cool new capabilities don’t sell themselves
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:
- The features never reached their full potential. All that time on upkeep? That’s time taken away from incorporating user feedback, fixing annoying little bugs, and putting in that next 20% to make it all really shine. The vision we started with got tested in only superficial ways. What was clear though, is that we couldn’t get there from here without either a major increase in team size (which brings its own set of problems), or much, much more time to work out the kinks. We didn’t want to do either.
- We didn’t have time to properly publicize and sell the features. This is key. We’re a lean team, and we all wear multiple hats. If we’re spending more time analyzing the performance of a particular MySQL index, we’re spending less time writing blog posts or forming partnership with other companies. The biggest hit we took during those months of building and stabilization was the corresponding decrease in sales and marketing.
Why you need sales and marketing
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.
The takeway
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.
That’s it … two lessons?
This is part 1 of 2. Subscribe to our RSS feed or follow us on Twitter for part 2.
