Build or buy is usually the wrong first question
The useful choices are rarely binary. A team can buy a complete product, configure a platform, compose several services with an automation layer, or build a narrow custom component around commodity infrastructure.
Start with the constraint. Is the problem speed, control, differentiation, compliance, reliability, or cost at scale? Different constraints lead to different answers even when the workflow looks similar.
1. Is the workflow part of your advantage?
Buy the commodity and build the distinction. Payroll calculation, password reset, and invoice delivery are rarely where a small company should invent new infrastructure. A unique qualification model, operational knowledge layer, or customer handoff may encode how the company wins.
Be honest about uniqueness. A process is not strategic merely because the current spreadsheet is complicated.
2. Compare the cost of operation
Subscription price is visible, so it gets too much attention. Add implementation, integration maintenance, monitoring, vendor management, training, data migration, and the cost of failures.
For a custom system, include the cost of ownership after the original builder leaves. For a purchased system, include the workarounds created when the product cannot express a critical rule.
3. Model the failure before the feature list
Ask what happens when the tool is unavailable, changes its API, loses a record, or makes a decision the team cannot explain. The severity and reversibility of the failure should influence the architecture more than a long comparison table.
CISA's Secure by Design guidance places responsibility on technology producers to make products secure by default. Buyers should still ask how access, logging, updates, and incident response work in practice.
4. Price the exit
A tool can be cheap to enter and expensive to leave. Check export formats, API access, identity ownership, domain ownership, data retention, and the amount of business logic trapped in proprietary configuration.
For custom components, document interfaces and keep the source, deployment, and service accounts under company control. Exit planning is not pessimism. It is a test of whether the business still owns its operation.
5. Choose the smallest custom surface
If the workflow contains one differentiating decision, do not build an entire platform around it. Buy identity, hosting, observability, and common integrations. Build the narrow rule or interface that expresses the advantage.
This approach reduces maintenance while preserving control where it matters. It also makes future replacement easier because fewer responsibilities are coupled together.
A weighted decision table
Score each option from one to five across strategic fit, time to value, three-year operating cost, security and compliance fit, integration effort, reliability, internal skill, and exit cost. Weight each criterion before scoring the vendors.
Then run a pre-mortem on the highest-scoring option. Imagine it failed eighteen months from now. Write the three most plausible causes. If those causes are not visible in the scorecard, revise the weights.
The goal is not to predict every future requirement. It is to make the current tradeoff explicit enough that the company can revisit it when the evidence changes.