Why is it so hard to decide to buy?

Build vs buy, the never-ending debate. Should we buy a vendor product, or build the system ourselves? Despite popular consensus that it is critical to focus on work that is core to our business, engineers the world over continue to build non-core products instead of buying them. What gives?

It’s hard to write about build vs buy because even raising the issue brings up a host of related challenges and problems that go the very core of our identities as engineers. What is the value of innovation? Is an engineer who doesn’t build from scratch really an engineer? How do companies reward people who save time and energy by resisting the temptation to build, instead of rewarding only the more visible outcomes of having built a new thing? What is cool, what is fun, what is pragmatic, what is good, and when do we even know that we have done the right thing?

There is no easy answer to this situation (despite my glib tweets), but it’s worth trying to unpack how we got here and ideas for approaching the question.

A tweet that generated a lot of feelings

Optimism and Fun

The default to building our own software is well-established at most tech companies. Some of the patterns that lead to this include:

1. We want to believe ourselves to be special, and our situation to be unique. We over-focus on the edge cases that are not perfectly solved by off-the-shelf tools, and ignore the complexity of providing the main features in addition to our desired edge cases. We believe ourselves to be better engineers and capable of solving the problem in a more-perfect way.
2. Building is fun, and the work of integrating an existing product often sounds tedious. As an industry we’re still struggling to move from telling engineers “your job is building brand new things from scratch”, and our whole style of teaching computer science is first-principles based, which encourages the default to build ourselves. The industry has not thought much about what makes someone good at integrations, or what the opportunities are for engineers who are doing integration work to learn new things and feel challenged and stimulated.
3. We underestimate the work of building, and the total cost of ownership of having our own special product. It’s easy to see the bill for your SaaS software every month, and hard to appreciate that the engineering cost to build an internal version is still probably higher because you haven’t factored in the opportunity cost of having engineers build that system instead of contributing to more core business opportunities. Perhaps you think that you can lessen this bill by making the project open source, and having community support for the effort. In reality, even if you somehow manage to build a community around it (an extremely challenging thing to do), now you have to balance moving the project forward in the way your company needs and moving the project forward in the way the community might need. Building OSS might still be the right call, but it’s not a free option.
4. Companies reward people who create new things. It is hard to identify and reward problems that are avoided. When it comes time to evaluate people, we look at systems built from scratch and believe their authors show more technical talent than those who completed similarly-challenging integration projects with less raw code. Most companies promote those who create new systems even of questionable value much faster than they promote those who might be making wiser choices by not building from scratch, which creates a pressure to build in order to grow your career.

Even with all of these factors favoring build, at some point most companies realize that they shouldn’t build everything, and try to pivot towards buying. Occasionally, you find companies that have built up almost entirely by buying and integrating, and they discover that they need to move towards building. In either case, there are some rules of thumb you can use to guide the decision.

Making the decision to build or buy

When you come across this situation, here are some questions to consider:

Is this software core to your business and its unique value? Will you need to change the product regularly to meet new business needs? Does it need to adapt to those changes quickly, on the order of days or (few) weeks, in order to keep up with the demands? These are indications that this is core to the business, even if the software isn’t the direct business logic.

Are you in a space where a combination of scale and functionality means that you need bespoke software to run your business? Then yes, this is your core business, and you should build! The trick here is going to be how much you should build. For example: you may need a better API and a service with some logic and caching to make the scale effective, but you rely on S3 for your underlying storage system. This is the area that most platform software engineering is moving towards; leave the negotiations with the hardware vendors for the cloud provider and use their best scaled options as components for your bespoke needs.

Finally, a grey area: is this a place where you can build a small and very focused tool that won’t need new features over time? Maybe this is an OK place to build, especially if most of the options are large and cumbersome to learn how to use. Be careful though, because if this is a product area that needs to grow over time, you can find yourself trapped in a bind where you spend a lot of energy expanding your bespoke offering but migrating to a vendor tool is also an expensive proposition.

If none of these options are true, do your best to find a SaaS solution (preferable, because most of the cost of software these days is in operations), or maybe an open source or vendor solution (each has their own plusses and minuses, but the biggest minus for both will be operations), and make it work.

What if there is no off-the-shelf solution that you can adopt but it doesn’t fall into any of these other categories? Then ask yourself the question: why has no one else encountered this problem and built a solution for it? It’s possible that you have found a business idea, but it’s also possible that you are solving a problem that may not need to be solved. If the solution is more than a trivial amount of work, spend that time reconsidering whether you need to solve this problem, in this way, before proceeding to design and build your future albatross.

You should expect that the decision of where to build or buy will change over the years. Ten years ago many E-Commerce companies had heavily customized or even bespoke technology platforms for running their website and inventory management. Over time, companies like Shopify have created richer and richer offerings that mean that most E-Commerce startups today don’t need a large tech team to build a bespoke platform. It is ok to make the decision to build based on today’s offerings, if you feel confident that there is nothing out there that is close to your requirements. But especially for software that is not core to your business, try to build the minimal set so that you can migrate to better options if and when they appear.

When integrations bite back

I have attempted to simplify the problem and solution, but there are a number of non-trivial elements to buying that are worth keeping in mind.

Problem 1: Buying a bigger solution than you need, and then feeling obligated to use all of it.

Jira might be the best example of this kind of abuse. Jira is a perfectly fine system for ticket tracking that can be made to do horrible, horrible things through customization. Just because the product can do a thing doesn’t mean you should use that feature! Over-customizing an off-the-shelf product can end up being the worst of both worlds: you are writing a lot of code and maintaining a lot of bespoke logic for a system you don’t really “own,” which tends to bring a lot of technical debt over time as the product evolves in ways that are incompatible with your customizations. Just because you are paying for a product doesn’t mean you have to use every bell and whistle!

Problem 2: Evaluating every option out there for every decision.

You do not have to do a bake off for every product you choose to adopt, really. It is ok, even good, to build into an ecosystem that works well together, that your team is comfortable with, where you have an existing relationship with the vendor. These are not bad reasons to choose a product (just try to avoid choosing a product because of your CEO’s golf buddies). There is a cost to delay of making a decision, so be realistic about what the really important factors are for choosing the product and try to otherwise move fast. When you agonize over every one of these decisions, you make the team less inclined to adopt something that they’re comfortable with and works and more inclined to just build their own thing to avoid the bureaucracy.

Problem 3: Over-vetting every product.

Similarly, if the process of approving a new vendor/SaaS/OSS product is slow and painful, there is every incentive for engineers to just build so they don’t have to wait for approvals to get started. Is this really want you want to happen? If not, figure out how to get the approval to use a product done faster, preferably in parallel to the team getting their hands on it to see how well it suits their needs.

Problem 4: Underestimating the work of integration.

Yes, integration is often the right choice in a cost-benefit analysis, but that doesn’t make it free. Think of the work involved in moving to the public cloud as an example of a really complicated vendor integration exercise. When you decide to adopt a vendor product that requires anything more than “enable this for everyone with a google account in my organization” expect that it will take time. And while you don’t want to over-vet everything, no product is perfect and the more sales people there are around the product the more likely you are to find some unexpected gaps in the offering that you may have to work around, so make sure you understand the core important features.

Problem 5: Neglecting to speak to the value of what the engineers are providing when they aren’t building from scratch.

You are still going to need software engineers, even if a lot of your underlying software is not bespoke. These engineers need to feel like they are learning, and growing, and they deserve to be part of these decisions. The integrations, automation, the shims you build on top to make a unified surface area for the users at your company, the fine-tuning of the use of the software so you don’t spend a ton of money, these are tasks for engineers. I run a platform engineering team, and must tackle the question of “what is platform engineering in the era of the public cloud.” I have yet to run out of software that needs building, despite moving more and more towards open source and SaaS components, but it is an ongoing process to explain to engineers who aren’t familiar with working on these problems why they are still interesting and fun even when you aren’t building everything from scratch.

You will need to look at your rewards structure if you want to encourage a move towards buying more and building less. If your career ladders talk about the size of system built, if you proudly announce brand-new from-scratch software that your team created and ignore the work that enabled the use of a SaaS tool, you are reinforcing the hierarchy of “build” over “buy.” People want to get promoted, they want to get kudos, they want to get paid, and you should do all of those things for your engineers who support the enablement and integration of off-the-shelf products.

Wrapping Up

If you believe your company to be a tech-driven company, there should be plenty of things for engineers to build, and even the integrations they are crafting will have meaningful engineering challenges. As a leader, you have to support their desire to innovate, experiment, learn, and build. Buying software is often the right decision for the business, but if you need to go deep into this path, you must challenge yourself to identify the meta-products that the team is creating to take these off-the-shelf solutions and turn them into a productive ecosystem.

Engineers, you owe it to yourselves to be thoughtful about the software you work on. Many of us have built bespoke platforms only to get burned out on the cost of maintaining and supporting them over the years, and there are other ways to learn about big systems that don’t require building everything from scratch. Bring your own creativity to the build vs buy discussion, and meaningfully engage with the question of where you want to focus your time and talents. You may find that you could have a more lucrative career if you become skilled at using and extending popular platforms, and there is no shortage of interesting work to be done in this space. Just don’t be the person who builds a glass sword.