Build vs. Buy: A Decision Tree for Your Next Internal Tool

A client we have worked with for a few years sends us roughly the same email twice a year. "Our team is asking for [some new internal capability]. Should we build it or find a SaaS for it?" Our answer is rarely the dramatic recommendation either of us hoped for. It is almost always a decision tree, and the answer at the bottom of the tree depends on five or six honest questions about the specific workflow. This post is that tree, written out long-form, so you can run it yourself before the email next time.

The tree assumes you are looking at a specific workflow, not a general SaaS-stack audit. "Should we build a CRM" is too broad to answer. "Should we build a tool that intakes inbound RFP packets, scores them against our capabilities, routes them to the right estimator, and produces the project sheet" is the specific kind of question this tree handles well. The narrower the workflow, the cleaner the decision.

Question one: is there a credible off-the-shelf option?

The cleanest possible answer to the build-versus-buy question is "yes, there is a SaaS product that does this exact thing, it costs a defensible amount, and our team already knows how to evaluate it." If that answer is honest for your workflow, buy. The engineering effort to build a credible alternative will almost never be cheaper than the subscription, the maintenance burden of running custom software you do not need is real, and the SaaS vendor is going to keep improving the product in ways your custom build will not.

The trap on this question is dishonesty about what "credible" means. A SaaS product that does 60% of what you actually need is not a credible option. A SaaS product that does 90% of what you need but charges per-seat in a way that breaks at your scale is not a credible option. A SaaS product that handles the workflow but does not integrate cleanly with the systems your team already lives in is, for practical purposes, not a credible option. Be honest. The whole point of the tree is to surface the workflows where the SaaS market genuinely does not serve you, and you cannot do that if you are gentle with the SaaS market's coverage of your needs.

If a credible option exists, buy and stop. If no credible option exists, proceed to the next question.

Question two: is the workflow strategic?

The next question is whether the workflow you are looking at is core to how the business competes, or whether it is a back-office function that just needs to work.

A workflow is strategic if your team's ability to do it better than competitors is a real source of advantage. A construction firm whose RFP intake process is faster and more accurate than its competitors' wins more work, because the team is the first to have a project sheet on the estimator's desk. A community bank whose loan-pipeline tracking lets relationship managers stay one step ahead of the customer's questions converts more pipeline into closed loans. In both cases, owning the tool that supports the workflow is part of being able to invest in making the workflow better over time.

A workflow is not strategic if it just needs to happen reliably without much variation. Accounts payable is a workflow. Payroll is a workflow. Most expense management is a workflow. None of these are sources of competitive advantage for most businesses, and none of them justify the engineering investment of a custom build.

If the workflow is not strategic, buy the best available SaaS for it and stop. If the workflow is strategic, proceed.

Question three: how often does the workflow change?

This is the question most teams underweight, and it is the one that most often decides whether a custom build is going to be worth its cost on a five-year horizon.

If your workflow changes annually because the underlying business changes annually (new product lines, new compliance requirements, new market conditions, new operational realities), a SaaS product is going to underserve you forever. SaaS vendors update their software on their own roadmap, not yours, and the gap between what your business needs this quarter and what the vendor has shipped this quarter is permanent.

A custom build, by contrast, changes when you need it to change. If a regulatory update lands in Q3 and your workflow needs to incorporate it by Q4, you can ship the change. If a competitor moves in a way that requires a tactical response, you can ship the response. The strategic value of being able to change your own software at your own pace compounds over years, and it is the value most teams miss in the build-versus-buy spreadsheet they put together.

If the workflow changes annually or faster, the case for building is meaningfully stronger. If the workflow is genuinely stable year over year, the case for buying remains strong even when no perfect SaaS option exists, because the maintenance burden of running custom software for a stable workflow rarely pays back.

Question four: who owns the data, and what does it become?

The fourth question is about the data the workflow produces. Specifically: is that data something your business should fully own and build other things on top of, or is it operational exhaust that the SaaS vendor can manage just as well as you can?

A construction firm's RFP-intake data becomes the input to better pricing on future bids, better selection of subcontractors, and better forecasting of upcoming revenue. The same firm's HR-onboarding data is just HR-onboarding data. The first dataset deserves to be owned in a way you can compose on. The second can live in a SaaS forever without anybody losing sleep.

The question is whether the data is going to feed downstream decisions, machine-learning models, or other internal tools that your business will build over the next several years. If the answer is yes, the data needs to live in a system you control, which usually means a custom build. If the answer is no, the SaaS vendor can hold the data and you can ask them for an export if you ever need one.

Our custom software service page discusses the data-ownership question in more depth, because it is the one we end up walking clients through most carefully.

Question five: can you maintain what you build?

The last question is the one that kills most build-versus-buy decisions that get the first four right. Custom software requires ongoing maintenance, and the maintenance burden is real. Security patches need to ship, dependencies need to update, the team using the software needs support, and bugs that show up need to get fixed. A custom build that ships without a clear plan for maintenance becomes a liability within eighteen months.

The good news is that maintenance does not require a full-time engineer for most internal tools. The bad news is that it requires a relationship with somebody who can do the work when it needs doing. For clients who do not want to hire an internal engineer, this is the work an ongoing engagement with a firm like ours handles. The custom tool we build remains supported by the same team that built it. The client pays a predictable monthly amount, the tool stays current, and the build investment continues to compound rather than decaying.

If you genuinely have no plan for maintenance and no appetite for one, you should buy regardless of how the other four questions land. A maintained SaaS that does 70% of what you need is more valuable than an unmaintained custom build that does 100%.

Putting the tree together

In practice, the workflows that should be built are the ones where: no credible SaaS option exists, the workflow is strategic to the business, the workflow changes regularly, the data it produces is data your business should own, and you have a credible maintenance plan. When all five conditions are present, building has been the right call for several years now, and the gap between custom and SaaS has been widening as AI agents make custom software easier to compose on.

When even one of those conditions is absent, the SaaS option almost always wins on cost and on operational simplicity. The discipline is in being honest about which conditions are actually present rather than which conditions you wish were present.

If you have a specific workflow on your mind and want a second opinion on how it scores against the tree, send us a quick note. We will give you an honest read, and if buying is the right answer, we will tell you that even though it does not put us on the project.