Six questions before you decide
The build-or-buy decision often looks like a question of price. In practice it is a question of what the organization needs to control and what it is willing to trust others with. The closer a capability is to what differentiates you, the stronger the case for controlling it.
Go through the questions below for each option. You do not need to give each one a precise score; it is enough to identify which questions are decisive in your case and which matter less.
- Differentiation: is this capability part of the value you sell, or infrastructure everyone needs?
- Data sensitivity: which data will pass through the service, and is it allowed to leave the organization?
- Total cost: what will it cost to build, run, maintain and update over time?
- Vendor lock-in: how hard will it be to switch if the terms or the price change?
- Time to value: when will users actually be able to use the solution?
- Team capability: is there someone who will maintain what gets built, a year from now as well?
Total cost includes operations
A vendor quote is easy to compare. The cost of building in-house is harder to see, because most of it arrives after launch: security updates, monitoring, incidents at night, version upgrades and onboarding new people. AI systems add model running costs and recurring quality checks on top of that.
The buy side has hidden costs too: customization, integration, price increases as usage grows and work around the product's limitations. Compare both options over the same time horizon and under the same usage assumptions, and mark which numbers are estimates.
Vendor lock-in and an exit plan
Vendor lock-in is not necessarily bad. Sometimes it is a reasonable price for speed and for operations someone else is responsible for. The problem starts when you have no idea what it would take to leave.
Before you sign, write a short exit plan. It does not need to be ready to execute tomorrow, but it should show that a way out exists and roughly what it would cost.
- Can you export the data, configuration and history in a usable format?
- Which parts of your code depend directly on the vendor's interface?
- Would a thin layer between your system and the vendor make switching easier, and what would it cost to maintain?
Managed service or self-hosted
The same question comes up in infrastructure. A managed service, such as a database or a language model behind an API, shifts a large part of operations to the vendor. Self-hosting gives you more control over data, versions and, at some scales, cost, but it requires people who know how to run it.
Kubernetes is a good example. It offers flexibility and standardized deployment, and at the same time adds a layer that has to be upgraded, secured and monitored. For a small team with a few services, a simpler managed platform may be a better fit. For an organization that already runs several environments and has a platform team, the calculation may be different.
Ask who will receive the alert when something breaks, and what they will need to know to handle it. The answer to that question says a lot about the right choice for you.
Capture the decision in a short record
Decisions like these are forgotten quickly, and their reasoning is forgotten even faster. An Architecture Decision Record (ADR) is a short document that captures the context, the options, the choice and the consequences. It helps the next team understand why the system looks the way it does.
Also decide when to revisit the decision: a date, a change in usage or a change in the vendor's terms. A good decision today may stop fitting a year from now, and that is fine as long as you can recognize the moment.
- Context: what the problem is and what the constraints are.
- Options: what was considered, including doing nothing.
- Decision: what was chosen and, in one sentence, why.
- Consequences: what gets easier, what gets harder and what the risk is.
- Review: under what condition or by what date the decision will be revisited.