Build-buy decisions are boundary decisions in disguise.
The question is rarely only whether a tool has features. It is whether the company is comfortable letting that tool own, copy, transform, or trigger changes to operating truth. A vendor may be excellent for workflow and dangerous as a source of record. An internal tool may fit the process and still create reconciliation debt if it invents its own object model.
Before buying or building, operators should ask what truth the system will touch. Will it create customers, update owners, change entitlements, calculate status, approve spend, route cases, or write back to finance? Each write path needs authority. Each copied fact needs a sync rule. Each derived field needs a definition owner.
Integration boundaries matter as much as product capabilities. A clean read-only integration is different from a bidirectional sync. A workflow tool that writes comments is different from one that changes account status. A product-led motion that provisions entitlements automatically needs stronger ownership rules than a reporting add-on.
This is not an argument against buying software. It is an argument against pretending tools arrive neutral. Every system imports assumptions about objects, statuses, roles, and handoffs. If those assumptions clash with the operating model, the company pays through exceptions.
The practical move is to add a truth-boundary review to major system decisions. Name the objects, authoritative fields, write permissions, downstream consumers, and failure paths before the contract is signed or the internal build begins.
A tool can be useful without being allowed to own truth. That sentence saves a lot of pain.
This is part 7 of 10 in Systems of Record.
