# Build, buy, or integrate? A decision guide AI-assisted editorial draft • Bill Allred review pending • Draft and sources checked 19 October 2026 ## Executive answer Choose the route that gives your business the required outcome, an inspectable way to check the work, and an owner capable of maintaining it. Compare the complete operating workflow, including exceptions and evidence, rather than the apparent sophistication of the AI component. Buying can be appropriate when an existing application fits the work and exposes the controls you need. Integrating can be appropriate when capable systems already exist but information and decisions do not move between them. Building can be appropriate when the workflow is genuinely distinctive or required controls cannot be achieved through configuration. These routes can coexist: buy a model service, build a narrow checking layer, and integrate it with an existing system of record. First ask a more consequential question: can the resulting system reliably check the output that matters? An attractive interface cannot compensate for an unverifiable business decision. ## Define the unit of comparison Write a short workflow contract before evaluating products: - What input arrives, from whom, and with what permissions? - What output or action must result? - Which authoritative records establish whether it is correct? - What can be checked automatically, and what requires judgment? - Who handles uncertainty, failure, and a change in business policy? Compare alternatives against this same contract. A purchased application that drafts a response and a custom service that posts a transaction are solving different problems. Their demonstration results and costs should not appear in the same column without adjusting scope. Make critical requirements pass/fail gates. Access boundaries, evidence export, required integration behavior, and a workable fallback should not disappear inside a weighted average. A strong convenience score cannot offset a failed mandatory control. ## Worked example: an illustrative service-parts workflow Consider a hypothetical distributor receiving requests for replacement parts. Employees currently find a product identifier, check inventory, and prepare a response. The proposed workflow extracts identifiers and drafts an internal recommendation. It has no authority to promise delivery dates or place orders. A ready-made application might handle messages well but offer insufficient access to the distributor's substitution rules. A custom build might reproduce the inbox unnecessarily. An integration could connect the existing inbox to product and inventory records, use a model to interpret the request, and run deterministic checks before presenting a recommendation. For this hypothetical situation, integration is the provisional preference. The deciding evidence is whether it can validate an exact product identifier, check the inventory timestamp, and reject substitutions absent an approved mapping. The final response still needs commercial judgment when the customer describes an unusual application. That exception should be visible and routed, rather than hidden inside a confident recommendation. The recommendation changes if the existing inbox cannot expose the needed records or if a purchased product passes the same tests with materially less maintenance. No route wins simply because the organization has already invested in a demonstration. ## Inspect the checking mechanism Ask each supplier or internal team to demonstrate a wrong answer being stopped. Request cases with missing records, conflicting identifiers, expired inventory, and unauthorized data. Have the system show the input, evidence, check result, and resulting action. Schema validation can confirm that a field exists and has the required type. It cannot establish that the selected part fits a customer's equipment. OpenAI's documentation explicitly notes that structured outputs can still contain mistakes. Treat structure as one useful control, then test the business meaning separately. [Official Structured Outputs documentation](https://developers.openai.com/api/docs/guides/structured-outputs) A model-based reviewer can help score ambiguous text, but must itself be tested against representative labeled examples. Ask what errors the reviewer misses, how disagreement is handled, and what happens when no dependable reference exists. Where correctness cannot be checked adequately, narrow the scope or keep that decision with a qualified person. ## Compare ownership and lifetime cost Use the downloadable matrix to compare evidence, not sales claims. For each route, identify who owns integrations, source data, test cases, access reviews, incidents, supplier changes, and retirement. Buying software changes the work you own; it does not eliminate operating responsibility. Include configuration, data cleanup, evaluation, training, exception handling, support, change testing, and exit costs alongside licensing or model usage. Record uncertain costs as ranges with an owner and a way to resolve them. Do not count employees' recovered time as cash savings unless the business has an actual mechanism to realize those savings. Test portability practically: export a sample case with its sources, decisions, and audit evidence. Determine which parts could move and which would need rebuilding. Contractual rights and technical export are separate checks. ## Decision and limits Recommend a route only after the mandatory gates pass, a representative test is complete, and named owners accept ongoing work. Otherwise record a conditional decision with the unresolved evidence and next test. This is an original decision method for review, not a product ranking or procurement assurance. No supplier pricing, commercial terms, security certification, or Altiport implementation capacity is asserted. NIST's voluntary AI Risk Management Framework provides broader risk context; using a worksheet does not establish compliance. [NIST AI RMF overview](https://www.nist.gov/itl/ai-risk-management-framework) **Next step:** complete the [build/buy/integrate decision matrix](https://altiport.ai/downloads/build-buy-or-integrate-worksheet.md) for one bounded workflow and compare the strongest two feasible routes.