Buy Don’t Build
A look at the real cost of building instead of buying.
I’m an engineer at heart and that means that I love to solve a problem. And even after all of my years developing, one of the hardest challenges is not building something. Luckily, I’ve learned the lesson that it’s almost always better to buy, not build. So for today’s post I want to take a look at why.
Every second you spend building something, you’re not building something else.
It’s an obvious statement, but time spent solving a problem someone has already solved is paid for in lost and delayed features. Technology is a rapidly evolving market, and a product that stands still for too long will be quickly replaced by a competitor. Everything you build needs to have value to your proposition; and buying in solutions means you can focus on what’s unique about your product.
It’s almost always going to be harder than you think it is.
One of my favourite flowcharts (and there’s a lot of competition in that field) was shared by Slack in response to the countless developers who said they could build Slack in a weekend. It’s a surprisingly common blindspot; complaining that people don’t appreciate how hard for you to just add that new feature, while simultaneously saying it can’t be that hard for a product you use to get something fixed.
It’s a fair assumption that the people you’re buying from aren’t employing 100 people to solve the problem because they like burning money. The devil is forever in the details; and often it’s the most trivial of services that mask the most complicated of problems. Sure- I might be able to write a blogging platform in a weekend; but it’s not going to be Medium.
You’re not just buying a feature, you’re buying experience and guidance.
This is perhaps the most subtle of the buy-not-build arguments, but it’s also one of the most important. When you buy a product, you are buying from a group of people who spend every day in that problem domain. Hopefully it’s obvious that means that they’ve become good, and efficient, at solving it- and therefore able to deliver the best solution and the best price.
But what’s not immediately obvious is that they are also constantly working at being the experts are how you approach a problem. For example, if you want to learn how to deliver a scalable system; take a look at the limits and constraints that permeate AWS. Amazon are experts at delivering scalable systems, and each one of these constraints reveal a usage hint that will guide you to delivering one too.
If you think you can do it cheaper, don’t forget to factor in developer time and on-going maintenance.
I can definitely deliver git that would cost less than the $7/user/month that Github want to charge me to run. The catch is that developers are expensive, and the cost/benefit will fall out of favour when you realise that there’s an ongoing development cost to keep the service maintained.
And maintenance is so much more than ssh-ing in a updating; it’s evolving the feature set to stay inline with what your company needs, and ensuring that you don’t end up with a key piece of your product that relies on a single person’s collection of idiosyncratic home-grown scripts. Before you know it you’ll have a liability of three people taking resources away and slowing down the development of your product; ultimately costing you much more than that original $7 you sneered at.
An accessible user experience is hard to hone and worth an incredible amount.
Finally, it’s is all too easy to forget that user experience is king. A simple and well polished user interface doesn’t just make your life easier- it can also unlock the product (and the knowledge within) to non-technical users. And the more people who can access information, the more who will be able to actionit into value.
At DevicePilot we spend a lot of time working on the user experience to ensure that not just developers, but everyone from customer services to CXO level people within a business can use it to derive the insights they need; a far cry from the inevitable bundle of scripts, spreadsheets and fragile web applications that internal tools end up being.
So the next time you find yourself thinking about building something you can buy; make sure you consider the real cost before you start.
