Build vs Buy
Is there a good choice?
When you set out to make a technology decision to solve a problem, you have a somewhat rough idea of what you want. That rough idea is the origin of the solution that will finally enable you to solve that problem and improve things for your company.
But, that decision isn’t easy. It takes some to manifest, with your own view, then to be relayed to the rest of the team/company. And often, you are stuck with a Build vs Buy question about the technology itself.
Let’s make that decision easier, shall we? It isn’t trivial and the implications of a wrong decision can be expensive.
Context
I’ve been on both sides of that question, in my career. Selling software versus building it, in-house, I’ve done both. But, both were at different companies and solving different problems, under different circumstances.
So, when you think it’s easy to build, you need to know what you are signing up for. I’ve built and it has been rewarding to see the results, but the pain to get there has been a teachable moment, or two.
Buying is the other side of that coin. Do you buy software from a vendor and let them ease your pain? Yes, you can. But, given your company's current or future plans, how easy or difficult it is to do, is for you to assess.
Let’s look at them individually.
Building
This choice means you’ve decided to solve the problem yourself. You are about to embark on evaluating solutions and implementing them on your own.
Why?
A few reasons why you (team/org) should choose building solutions:
You have a history of building tooling and solutions in-house. This is how it has been and your team has the know-how to execute.
You’ve invested in a lot of home-grown tooling to help facilitate easy solutions to be built.
Integration of any other outside solution is harder in your ecosystem. You might be doing custom things that align well with your business but aren’t generic enough to plug in something external.
You worry about cost or some other factors that might hurt your progress when you bring in something external.
No external solution makes sense for the problem you are solving.
Good
What do you gain by going down this road?
The tooling you built will be your own to run and maintain. No external interaction. Total solitude :)
You can monitor, track and iterate as much as possible with the tooling. Assuming your internal customers are ok with it, of course.
You have control and can upgrade without external dependencies.
Bad
What can go wrong?
You invest time that you may not have. The cost you put into building is the time and resources you have at your disposal. If you can’t afford to do that, it might end up being a wasteful endeavor.
More often than not, a home-grown solution hasn’t completely solved the issue or set up a better story going forward. You are stuck with what you have built and sunk cost fallacy stares at your face.
Your team might not have the right experience, so the solution can have holes and inefficiencies that might go undetected for a while.
Buying
Why?
A few reasons why you (team/org) should choose buying solutions:
A small(ish) company that isn’t technology-savvy typically relies on expertise to help them out. Even the smallest thing is outsourced until they build out their own muscle.
When the problem isn’t something within your company’s core domain.
When you’ve solved a problem by yourself, but it has been hard to maintain the solution, and keeps you up at night thinking about it.
Early enough, as a company iterates, it does the most logical thing and buys solutions instead of focusing on building them. Gets you unblocked and helps you focus on your core tenets.
Good
What do you gain by going down this road?
Peace of mind. A solution is handling your troubles and you can rest assured that they are there when things go wrong.
Your team is unblocked and doesn’t have to worry about building or maintaining this aspect and the burden has been offloaded.
Moving to a purchased solution saves you time and effort that you would have otherwise added to build something that couldn’t have been this good.
Bad
What can go wrong?
Products can falter and fail at any time. There are SLAs and Support for a reason. So, you have to deal with that.
As with building, there is a possibility of this not being perfect. You have to re-evaluate and spend more time with the vendor as they grow and iterate.
You are bound to the troubles that come with the solution. Not just downtime, but vulnerabilities, bugs, and upgrade timing, all of these are possible.
Integration can be hard. It might fit well initially but if other areas in your company are misaligned to what you’ve purchased, you are going to have to solve that problem.
Why not both?
Would you buy all the products your team needs? No. Would you build everything from scratch? Good luck.
Most companies find a hybrid model that works in their favor.
Large infrastructure pieces are typically purchased - think Cloud.
Smaller things like tooling for HR, Finance, IT, etc are purchased since they don’t align with company expertise and frankly, you don’t need to worry about those things.
Even specific tooling as you set up your (e.g. data team) can be evaluated to see which (Build vs Buy) makes sense. But, beware, these decisions are hard to turn around, so be pragmatic.
In either case, I’d recommend doing POCs and cost estimations to make sure your money is spent wisely on one or the other choice.
Until the next post, thanks for reading.
Stay encouraged.