Buy or Build?

Buying an existing software – wheter off the shelf or an existing company – or deciding to implement it yourself is a recurring, yet extremely important decision software executives have to make.

It's a decision they'll have to live with for years, if not decades, and the cost of correcting course in the event of a bad decision may simply be too high. It is therefore of the utmost importance that the right decision is made when faced with this choice.

The 3 scenarios

There are 3 common scenarios when it comes to the buy or build decision:

1. Build from scratch
2. Build from an existing codebase (ex: company acquisition)
3. Use a turnkey software solution

Let's examine the key points of attention for each of them!

When not to build

First, there's a clear rule for when not to build: if the software isn't core to your business.

For example, HR software, intranet systems, etc. There are plenty of off-the-shelf solutions that can be customized to fit your needs. You won't win the race there, so don't bother reinventing the wheel.

Unless you have a very specific case that justifies it, you should only decide whether to buy or build if it is core to your business.

Software isn’t a car engine

I have seen a lot of horror stories in my career because software executives without a technical background think that buying software is like buying a car engine. Some kind of clean, drop-in operation with only a few interfaces to connect.

But building a product is a very complex endeavour, and messy codebases are rampant in the industry. Using an existing codebase often means having to deal with something like this:

An existing codebase is typically hundred of thousands — or even millions of lines of code that:

• Might not have been written with technologies relevant to your project
• Might not follow best practices
• Might not follow a coding standard
• Might contain lots of bugs
• Might not be properly documented (or at all)
• Have been written by people that are not on your team (can take years to learn it all and be fully productive)
• Might implement hundreds or thousands of features that aren’t exactly what you want or aren’t useful at all. Cleaning things up is very expensive (architecture changes, unforeseen side effects, …)
• Might not be secure (enough)
• Might not be performant (enough)
• Might not be scalable (enough)
• Might not be reliable (enough)
• Might not be maintainable (enough)
• Might not be configurable (enough)
• Might be badly architected
• Might contain technical debt (slows down development by a factor)
• Might not be covered by an automated test suite to prevent regressions
• And many, many other factors…

Keep your ego in check

The other main reason for bad acquisition decisions is that software executives couldn't keep their egos in check.

Despite evidence that building from scratch was a far better approach, they couldn't resist buying an existing company so they could say on their resume that they led a multi-million dollar acquisition, only to regret it a few years later when they realized the inevitable failure of their project.

”What’s best for the company?” should – as always – be the only deciding factor.

Vendor lock-in

We mostly have 2 scenarios here:

1. The software solution is satellite to your main project (ex: data processing platform)
2. The software solution is the foundation of your project (ex: a low/no-code platform)

In the first scenario, a bad decision can be easily undone by switching to another solution.

But in the second scenario, vendor lock-in should be a major concern. Because you're building on an existing foundation that's not yours, you're highly dependent on the vendor, its roadmap, and its survival as a business. In this case, be sure to evaluate the solution thoroughly for a few months and test the riskiest assumptions before making a full commitment.

Sunk cost fallacy

The sunk cost fallacy is our tendency to continue with an endeavor we've invested money, effort, or time into – even if the current costs outweigh the benefits.

It's a common decision pitfall when it comes to the buy or build decision. Not wanting to admit their mistake, software execs postpone the decision to stop, believing they can turn things around, when in fact they’re just digging themselves in deeper and reinforcing the vicious cycle.

Humility and responsibility are therefore essential traits to ensure a successful buy or build project.

How to build from scratch

So, as you've seen, beyond the obvious situation where buying turnkey software solutions that are not core to your business or used as satellites makes sense, it's a much more complex situation when deciding to buy or build when it comes to your foundation.

As a general rule, I believe you should keep control of your tech stack. Your tech strategy is an integral part of your business strategy, and building things from scratch can be much easier and faster than building on top of an existing codebase.

With the right practices in place, such as focusing on an MVP (minimum viable product), using lightweight technologies, and the "few good people" model, your product will be in the hands of users while you would still be conducting audits and negotiating purchase agreements in the buy scenario.

Conclusion

The buy or build decision can often be a real challenge, and its consequences – good or bad – can be very long-lasting.

It is therefore highly advisable for the software exec to surround himself with people who can best advise him, and proceed with caution to ensure the success of the future project.