By Anshu Sharma, Co-founder and CEO of Skyflow

“To build, or not to build?” remains the most important choice companies face as they confront the new challenges, requirements, and demands required to scale their business. 

In May, A16z published a widely debated article called The Cost of Cloud that discusses the pressure that cloud costs put on a company’s margins. They’re not wrong — but the debate deserves a more holistic view of the invisible costs of building software you could buy. 

So, how should you frame your build vs buy decisions? What are the costs of building vs buying software, and what do we overlook when we only consider visible costs, like dollars spent? 

The visible costs of building software

• Cost of engineering talent to build it (Capex): How many engineers per year would you need to build this product from scratch? This includes replicating not just features, but the reliability and maturity of the services, as well as documentation and training. 
• Cost of engineering talent to maintain it (Opex): How many engineers per year would you need for support, operations, ongoing maintenance, repairs, bug fixes and new feature work? How much time would your engineering talent need to keep up with the latest domain-specific innovations in the industry? 
• Infrastructure costs to operate it: What are your predicted infrastructure costs today? How do they grow as you scale.
• Compliance costs: How much time would it take after the solution is built and implemented for it to get certified with the required certifications? What resources would staying compliant cost you? Not only are the fees for being non-compliant hefty, laws and regulations are changing daily and require significant investment to stay on top of.
• Opportunity cost: What does building software that you could buy cost you in terms of innovation? Or put another way, what core business value will you delay building because instead you’re building software that you could buy.

While these are good costs to consider, there are other equally important questions to assess. First among them: If you choose to build, do you have engineers with the specific skills required? If not, then factor in the time needed to hire and onboard them.

Recruiting world-class engineers isn’t as easy as swiping your credit card

Hiring certainly doesn’t happen on-demand. Recruiting and retaining high-quality engineering talent is a huge bottleneck to scaling and building any software. If you’re building components or features that are well understood such as a backend for your app, or a mobile app, you may already have the right skills on your team, or can hire for those skills.

But if you are building something more specialized like a messaging service that needs to interact with telecom APIs to send texts, or an identity authentication service that needs to meet an extremely high “up-time” SLA and integrate with dozens of apps — you could be signing up for a lot. The question to ask here is: Can I build this product or service quickly enough to have it ready when I need it?’

What are you deprioritizing?

Considering how difficult high-quality engineering talent is to obtain, what’s the true opportunity cost of building a solution that you could have bought? Instead of building something that you could buy, are there features you can build instead that will give you a greater market share, increase competitive advantage or serve your customers better?

So, you should ask yourself, what features are you deprioritizing or delaying on your roadmap to accommodate building a set of features you could buy? The more carefully that you consider these tradeoffs, the more clear it becomes that building software that you could buy rarely makes strategic sense.

Can you accelerate your go-to-market?

Along with vision, speed of execution is what matters in tech. Optimizing for speed means ruthlessly prioritizing the differentiating features of your offering and getting it to users quickly. Even if you had unlimited resources as far as money and engineering talent, you still wouldn’t have unlimited time. So, no matter how well funded your company is, it will never make sense to build all of the capabilities that you require. That’s why it’s critically important to be mindful of what makes the most sense for you to build.

Picking the “buy” option can mean accelerating your go-to-market by months (or even years!). So your question shouldn’t be ‘can I build this?’ but ‘should I?’

Solutions that meet your needs

If you find a solution that meets your needs, it almost never makes sense to build. 

On the other hand, if a solution needs extensive customization to cover your use case, or you can’t find anything on the market that comes close to what you were looking for, building is your best bet. If your use-case is on the fringes of the value proposition of what you’re buying, or you won’t be using it as intended, it will cost you time and money in the long run. Don’t put square pegs in round holes!

Trust

Another element often overlooked while buying a product is the team behind it. If you’re buying a solution from a team you trust, you can think of them as a force multiplier to your core product. They become an enabler, and as Zack Kanter puts it “you’re effectively buying autoscaling, on demand top talent.” 

When is building the right approach?

Building is the right thing to do in lots of different scenarios, but in general it can make sense to build software you could buy if:

• You’re building a core part of your value propositions and competitive differentiation. This is especially true when you have solid domain expertise, and what you’re choosing to build is part of your core competency. 
• You have the engineering talent (fungible R&D) to buid it, or time to hire and train engineers, and you operate at scale. This makes the most sense if your company is large and will use this software at a scale that doesn’t fit with software you could buy. 
• You should absolutely build software when your needs are unique. If you have very specific needs, and you can’t find a solution that fits your unique needs as a company, then you should build what you need.

On the other hand, if there’s a solution available that directly solves your needs and is built by a team you trust, the right answer is to buy. The indirect advantages of freeing up space on your roadmap to solve problems that differentiate you as a company, and shipping faster, can’t be understated.

Make an informed decision

Lastly, make this build vs buy decision after holistic evaluation of the visible and invisible costs. Use a structured decision making framework to avoid heuristic-based decision making. In his whitepaper ‘A Structured Approach to Strategic Decisions’ Kaheneman discusses evaluative judgements — places where you need to boil down large amounts of complex information to a decision, like whether to build or buy. In such decisions, you need to watch out for cognitive biases like availability bias, confirmation bias, and excessive coherence. 

Carefully weighing both invisible and visible costs can help you reduce the errors in your decision making and judgment process.