The build vs. buy question used to be slow. A team would compare features, run a pilot, negotiate a contract, and live with the choice for three years. AI has compressed that timeline to weeks, and the cost of choosing wrong has gone up. A bad SaaS pick still gets you something. A bad build burns six months and a budget cycle.
We get asked the same question on most first calls. "Should we buy the off-the-shelf tool, or have you build it for us?" The honest answer is that it depends on four things, and the four things are not the ones operators usually lead with.
What most teams get wrong
The instinct is to start with price. A monthly license fee per user, multiplied by seats, multiplied by months, compared to a one-time build estimate. Multiply, compare, decide. This math is almost always wrong, because it ignores the three costs that actually matter: the cost of the tool not fitting your process, the cost of switching later, and the cost of the people you need to operate it.
The right starting question is not "what does it cost." It is "what happens to this tool in eighteen months." That single reframe changes most decisions.
The four things that actually matter
When we sit down with an operator to make this call, we look at four dimensions. Each one has a clear answer that pushes toward buy, and a clear answer that pushes toward build. Most decisions become obvious once all four are on the table.
1. How unusual is the workflow?
If the work you are trying to automate looks like the work a thousand other companies do, somebody has already built software for it. Invoicing, scheduling, email marketing, customer support tickets. Buy. The SaaS is going to be better than anything you commission, because the vendor has spent ten years finding the edge cases you have not thought of yet.
If the workflow is specific to how your business actually operates, the calculation flips. Custom intake processes, unusual approval chains, a way of pricing that only makes sense in your industry. A SaaS tool will force your team to change how they work to fit the software. Sometimes that is fine. Often it is the reason the tool sits unused six months in.
2. How often will the workflow change?
SaaS tools are designed to be configured, not redesigned. If your process is settled and unlikely to change much, that is a fit. If you are still figuring out the process, or if it changes every quarter because the business is growing fast, a SaaS subscription becomes a cage. You will end up paying for features you do not use and waiting for the vendor to ship the one feature you actually need.
A custom build is the opposite. It is expensive to ship the first time and cheap to change after. If you expect to be tweaking the workflow for the next two years, custom usually wins, because the tweaks are where most of the value lives.
3. How sensitive is the data?
Some data is fine to hand to a vendor. Marketing copy, public company information, anything you would happily put in a public document. Buy without much thought.
Other data is not. Patient records, financial details, internal strategy, anything covered by a regulation, anything that would damage trust if it leaked. With SaaS, the data lives on the vendor's systems under the vendor's policies. That is a tradeoff some businesses can make and others cannot. When the answer is "cannot," custom is not really a choice, it is the only option.
4. How important is this to the business?
Tools that handle work nobody talks about at the board meeting should be bought. Expense reports, scheduling, internal wikis. The cost of switching later is low because the work is not strategic.
Tools that touch the thing your business is actually known for deserve more thought. If a customer's first impression of your company runs through this tool, or if the tool is what makes your product better than the competition, owning it matters. The SaaS option still might win, but the question gets serious, because you are now considering whether to rent the thing that makes you different.
The matrix
Put the four dimensions on a grid and most decisions sort themselves out.
- Common workflow, stable process, low-sensitivity data, not strategic. Buy. Do not even hold a meeting about it.
- Specific workflow, changing process, sensitive data, strategic. Build. The SaaS will not survive contact with reality.
- Anything mixed. This is where the work is. Most real decisions land here, and the next section is for them.
The three conditions where the obvious answer flips
Even when the matrix points one way, three situations change the answer.
Condition 1: The SaaS vendor is the wrong size for you.
A startup vendor with twelve customers will treat you like a partner and ship features for you. They will also be acquired or shut down in two years, and you will be migrating in a panic. An enterprise vendor will be stable but will not return your calls until you are one of their larger accounts. If the only available SaaS is too small to trust or too big to influence, build becomes more attractive than the matrix suggests.
Condition 2: You do not have an internal owner.
A custom build needs an internal person who understands the workflow well enough to keep improving it. Not a developer. An operator who knows what the system is supposed to do and can describe what is wrong when it stops doing it. If that person does not exist and cannot be hired, buy, even when the matrix says build. A custom system without an owner becomes a liability inside a year.
Condition 3: AI changed the math on this specific workflow in the last twelve months.
This is the one most operators miss. Workflows that used to require a SaaS vendor's prebuilt machine learning models can now be built in a week using general-purpose AI tools. Document extraction, simple classification, drafting routine messages, summarising long inputs. The build cost on these has dropped sharply in the last two years. If you looked at one of these workflows in 2023 and concluded "buy," the answer might be different now. Worth a second look.
What to do this week
Pick the three tools you spend the most on, and the three workflows that consume the most senior time. For each one, run it through the four questions. Do not try to reach a conclusion. Just write down the answers.
Most operators discover two things from this exercise. The first is that one or two of their current SaaS tools are in the wrong quadrant and should be replaced or rebuilt. The second is that one or two of the workflows they assumed needed custom builds can now be handled by software they could subscribe to this afternoon.
Neither result is the exciting one. Both are the kind of decision that compounds quietly for years.
When to ask for outside help
If the matrix is clear, you do not need us. Most build vs. buy questions answer themselves once they are written down.
The decisions worth a conversation are the ones in the middle. Workflows that are partly common and partly specific. Data that is sort of sensitive. Processes that might stabilise next quarter or might not. These are the questions where an outside perspective is useful, because the people inside the business are too close to see whether the workflow is actually unusual or just feels unusual from where they sit.
That conversation is short. Usually one call. The output is not a proposal, it is a recommendation, sometimes for us to build, sometimes for the operator to go subscribe to a tool and stop thinking about it.
That is the version of this work worth doing.
