Don't build features you can't afford to maintain
October 31, 2017•797 words
It’s fun and pleasurable to make children. In fact, it’s orgasmic. But, there tends to be an upper bound on the number of children a couple could bear. At some point, the couple presumably understands that another mouth siphoning scarce resources would be detrimental to the entire family, and cannot possibly be sustainable. I’m sure you see where I’m headed with this.
Building new features is highly fun and entertaining. In fact, you might even call it the orgasm of the technical world. You’ve brought forth new life that had not been present before. With a few lines of code, a few third-party libraries here and there, your app is now capable of new things, and you couldn’t be prouder.
But there is a high cost to these violent delights. Adding features is a weapon that should be used sparingly. Here's why:
Once you add a feature, you won’t be able to remove it without causing mass upset.
Really think about this one. It’s kind of scary. Consider every feature you add absolutely permanent. You will have to maintain this feature for the rest of your application’s life, which for your customers' sake, I hope to be many decades. The more technically impressive your feature is, the higher the cost to maintain it. And if your feature relies on a third-party library for its core functionality, you are in for a world of pain. On top of your pile of daily incoming bug reports regarding just core app functionality, you’ll have a new pile just for this impressive feature, with bugs you can’t begin to fathom, existing somewhere inside the 20,000 line third-party library.
Really really consider how much you care about your product before adding features as quick as customers request them. You’ll be doing your company and your customers a disservice if you don't.
If your new feature is not perfect, your reviews will suffer.
You could have a 5-star product, with unmatched stability and performance. But the moment you add a minor feature somewhere very deep inside the app, that only 1% of your users will ever even get to, and that feature doesn’t work as intended, your reviews will suffer. Five star reviews will turn into one star reviews detailing the upset you’ve brought users to their day. You cry No fair! What about all the other great parts of the app? But thus is human nature. You could win the lottery one moment and be filled with joy, but stubbing your toe a moment later will instantly ruin your mood. The feeling a user has towards your product will, for the most part, be relative to their most recent experience. You want to try to minimize the number of places things can go wrong. This is why I call my product Standard Notes. It minimizes features so you never have to worry about stubbing your toe.
Your product won’t survive as long.
I’d like to posit that a business that adds features recklessly will survive for a shorter period of time than it otherwise would have. Features means lines of code, and lines of code means maintenance and bugs. And there’s a sort of concurrency problem with labor. You could have a trillion dollar corporation with infinite resources, but there’s still a limit to how many engineers you can hire and manage, and can work concurrently on a given project. Thus, adding features and maintaining them is not something that can be hacked to your advantage with capital and resources.
Most importantly, adding features is probably not the solution to the problem you’re having. For me at least, adding features is a sort of defense mechanism I employ when I’m not sure what else to do to grow. Sometimes, adding features could be exactly what your app is missing, but this is rare. In most cases, your sales are low not because your app is missing some shiny feature, but because of other fundamental issues in another department, like marketing or customer service.
Recently, a somewhat-competitor of Standard Notes added a new feature to their app: an Apple Watch companion application. It was actually really nicely done, which means they spent some time on it. This was good news to me. I don’t believe a watch app is necessary for a notes app, and those scarce resources could have been directed to much more important problems. Instead, they chose to use their resources to build a complicated feature with little ROI. At this rate, all I have to do is continue pacing myself, and I have the potential to outlast them on stamina alone.
Finally, heed this warning from a guy who will be perpetually enslaved to a feature that all his users could have probably lived without:
