Every option buys one advantage by accepting a future obligation.
Build, and the company owns operation and evolution. Buy, and it owns integration and vendor constraints. Adapt, and it owns the mismatch between the old abstraction and the new work. Stop, and it owns the cost of leaving the outcome unmet.
The decision is which obligation the company is prepared to carry.
State the capability the company needs
“We need a feature store” starts with a product category. “Online and training code must use the same approved customer attributes, and every change must be traceable to an owner” states the capability. The second version leaves room for a vendor, a small internal service, an extension of the current data path, or a decision that the inconsistency is not yet costly enough to fix.
The capability should include the operating bar:
- which result must improve;
- who uses and operates it;
- which failures are unacceptable;
- how quickly the company needs evidence;
- which constraints come from security, cost, or regulation.
This prevents each option from quietly solving a different problem. It also exposes cases where a process change or a smaller existing tool satisfies the need.
Ask where differentiation lives
Custom work is most defensible when the capability encodes knowledge that changes the company’s result and cannot be obtained with acceptable constraints. Commodity work can still require engineering, but ownership of every layer does not create strategic value.
I ask which decision the company must make better than others. If the answer lives in a policy, model, workflow, or data asset, we may own that layer while buying the infrastructure around it. If no layer creates an advantage, speed and operating fit should dominate the choice.
This is also a test against pride. Engineers may enjoy building the system, and executives may enjoy announcing a partnership. Neither is evidence that the option serves the outcome.
Price the full ownership path
The relevant cost begins before launch and ends after the option is replaced. I estimate:
| Cost | Question |
|---|---|
| Adoption | What integration, migration, training, and process change are required? |
| Operation | Who handles incidents, upgrades, capacity, and support? |
| Constraint | Which product choices become harder because of this option? |
| Failure | What happens when the option is wrong or unavailable? |
| Exit | How do data, workflows, and customers move to the next option? |
A vendor can reduce implementation time and create integration or concentration risk. A custom system can fit the workflow and create a permanent operating obligation. Adapting an existing system can be fast until its original assumptions fight the new workload.
I do not collapse every factor into a precise-looking score. The estimate should reveal which assumptions control the decision and where the cost becomes irreversible.
Test the hard assumption first
Each option usually has one question that marketing material or design documents cannot answer.
For a vendor, it may be whether the product handles our real data boundaries and failure modes. For a build, it may be whether a small team can meet the latency target with an operable design. For adaptation, it may be whether the current abstraction survives the new access pattern.
I design the cheapest test that could eliminate an option. A trial using representative data and a failure exercise is more useful than a broad proof of concept that demonstrates only the happy path. A short custom spike should measure the disputed constraint, not become an unofficial first release.
Keep an exit
Reversibility has value when evidence is weak. I prefer boundaries that keep company-specific policy and data portable, even when the first implementation uses a vendor. For a custom build, I want milestones that produce usable evidence before the full investment is committed.
The exit does not need to be free. It needs a known cost, a trigger, and an owner. “We can migrate later” is not a plan if the data model, workflow state, and customer contracts all assume the current option.
Allow stop to win
Stopping is the correct choice when the outcome no longer matters, no option clears the operating bar, or the evidence needed to justify the investment is unavailable. Removing stop from the comparison turns prior enthusiasm into a constraint.
A stop decision can be bounded. The company may pause until demand reaches a threshold, a dependency exposes a required capability, or a smaller manual process shows where automation pays. The review trigger should be explicit so the question returns when its facts change.
The final decision should name the outcome, chosen option, rejected alternatives, governing evidence, total ownership assumption, exit trigger, and next action. That record makes it possible to change course without pretending the earlier decision was irrational.
I will sign the decision when it names the outcome, the obligation we are accepting, the evidence that eliminated the alternatives, and the condition for leaving. “Build versus buy” is too small a question for that record.