Don't stop here
Hand-picked guides our readers explore right after this one.
Stunning image generation with Midjourney prompt mastery
Read the guideExpert guide to Claude prompts with XML tags, artifacts, and complex reasoning
Read the guideMaster the 8-step framework for writing prompts that get results
Read the guideArchitecture and investment guide · Checked August 13, 2026
The decision is not a contest between an internal model and a software subscription. It is a choice about differentiation, control, speed, data, total ownership, and who carries the risk when the workflow changes or fails.
Michael Okeje
AI architecture and total-cost research · Last updated August 13, 2026
The first question should be “What outcome must the business reliably produce, and which parts of the system create or protect that value?” A team can build a beautiful model and still buy the surrounding identity, storage, monitoring, retrieval, payments, or workflow platform. Another team can buy a strong model and create its differentiation through proprietary context, process design, evaluation, integrations, and distribution.
AWS's build-versus-buy discussion calls this middle path “tailor”: start with existing building blocks, then adapt them to the organization. Its machine-learning guidance also warns against ignoring data-scientist time, infrastructure, maintenance, security, and performance when comparing a custom model with a pre-trained one. Those are useful reminders that build and buy are not single line items. They are operating commitments.
Fits: A standard workflow where a product already meets the material requirements.
Advantage: Fastest path to a supported capability and clearer initial cost.
Tradeoff: Roadmap, data practices, integration limits, and vendor dependency.
Choose it: When the capability is important but not your differentiation.
Fits: A differentiating workflow or requirement that products cannot meet.
Advantage: Maximum control over behavior, data, integration, and roadmap.
Tradeoff: Engineering, security, evaluation, maintenance, and support become yours.
Choose it: When control and differentiation justify permanent ownership.
Fits: Existing components cover the hard infrastructure but your workflow needs adaptation.
Advantage: More speed than a blank-sheet build and more fit than off-the-shelf software.
Tradeoff: You still own integration, configuration, evaluation, and some provider risk.
Choose it: When the center is commoditized but the edges matter.
Fits: The outcome matters but internal capability or capacity is missing.
Advantage: Access to implementation expertise and a managed operating process.
Tradeoff: Service dependency, knowledge transfer, and potentially higher recurring cost.
Choose it: When a managed pilot can teach the team what to productize.
The matrix below is a starting point, not a mechanical answer. Score each criterion from 1 to 5 for every option, write the evidence, and mark any hard requirement that cannot be traded away.
| Criterion | Question | Reading the answer |
|---|---|---|
| Differentiation | Would this workflow give customers a reason to choose us or improve a core advantage? | Build or tailor if yes; buy if it is a common utility. |
| Requirement fit | Can available products meet the quality, latency, integration, privacy, and control floor? | A failed non-negotiable requirement rules out a simple buy. |
| Data advantage | Do we have legitimate data, feedback, or domain expertise that improves the system? | Data helps only if it can be used, governed, and maintained. |
| Ownership capacity | Can we staff engineering, security, evaluation, operations, and support for years? | If not, buying or partnering may reduce risk. |
| Time horizon | How quickly must the workflow produce value, and how long can requirements evolve? | Buy or tailor to learn quickly; build when the long-term case is clear. |
| Total cost | What is the full cost over three years, including exit, change, and failure? | Use ranges and scenarios; do not compare license price with build salary alone. |
A high build score does not mean “hire a team and start coding.” It means the business should investigate what it would own and whether that ownership is worth the long-term burden. A high buy score does not mean “accept the demo.” It means run a representative test and complete the vendor review.
A buy decision is often compared with a build estimate that includes only initial engineering. A build decision is often compared with a vendor quote that excludes integration, support, review, and exit. Put the same categories against every option:
Use low, expected, and high cases. The high case should include growth in volume, model or vendor price changes, additional review, security work, failed integration, and a migration event. If a product is inexpensive but impossible to export, its exit cost belongs in the model.
A 250-person professional-services firm wants an assistant that answers questions from internal policies and project documentation. A vendor can launch in six weeks, but its export and retention terms need review. An internal build offers more control but needs an engineer, a data owner, security review, evaluation, and ongoing maintenance. A tailored option uses an existing model and retrieval components while the firm owns the permissions, document pipeline, evaluation set, and user experience.
Best if the vendor passes the data, access, citation, quality, and export gates. Fastest path, but the roadmap and data terms remain external.
Best if the assistant itself becomes a competitive capability or the requirements cannot be met otherwise. Highest control, highest ownership burden.
Best for learning and workflow fit. It keeps the core model replaceable while the firm builds the context, permissions, evaluation, and process knowledge that matter.
The likely answer is not permanent. Start with a supervised tailored pilot, set an exit test, and use the evidence to decide whether the workflow deserves deeper internal ownership. That sequence preserves speed without turning the first vendor choice into architecture forever.
Some requirements can be weighted. Others should stop the decision. Examples include an unacceptable data-use term, inability to restrict access, no route to remove or export required records, quality below a safety threshold, no human fallback for a consequential action, lack of a responsible owner, or total cost above the approved limit even in the expected case.
For vendor-specific due diligence, use the AI vendor evaluation checklist. For an internal or tailored system, connect the choice to AI governance and AI evaluation.
Start with the site's AI pilot plan, then use how to calculate AI ROI to test whether the choice creates value rather than just activity.
Buy when the workflow is common, a credible product meets your requirements, speed matters, and the capability is not a differentiator. Build when the workflow is central to your advantage, available products cannot meet a material requirement, you have the data and team to operate it, and long-term control justifies the cost. Tailor existing models, APIs, and components when you need meaningful customization without owning every layer.
Tailoring is a middle path: buy or use existing components, then configure, integrate, evaluate, and extend them around your workflow. A managed service or implementation partner is another middle path when you need expertise and an outcome without hiring a permanent internal team. These options are especially useful while requirements and usage are still changing.
Not by default. Compare total cost of ownership: data preparation, engineering, infrastructure, model evaluation, security, monitoring, upgrades, support, and the opportunity cost of the team. A custom model may be justified by a specialized performance, privacy, latency, or cost requirement at sufficient scale, but a lower API bill alone does not prove that building is cheaper.
Buy when the product solves a standard problem, can handle your data and controls, passes a representative quality test, has acceptable commercial and exit terms, and can be implemented faster than an internal alternative. Put the tool through a bounded pilot first, and avoid connecting sensitive data until the vendor evaluation is complete.
Custom work becomes more attractive when the workflow creates meaningful differentiation, the available products cannot meet a critical requirement, your organization has legitimate proprietary data and operational expertise, the volume or latency profile changes the economics, or control over the roadmap and data is strategically important. It is still a product with ongoing maintenance, not a one-time project.
Define the workflow and non-negotiable requirements, estimate total ownership cost for each option, test available products on representative cases, assess data and security, score differentiation and control, map implementation capacity, and test the fallback and exit path. Document the assumptions and choose the option that can deliver the required outcome with the least unacceptable risk.
A useful architecture question is not “buy or build the whole thing?” It is “which layer creates or protects durable value for this business?” A company may buy a foundation model, tailor retrieval, build permissions and evaluation, and use a partner for deployment. Another may buy the full workflow because its differentiation is in service, distribution, or domain expertise rather than software.
The layers most often worth owning are the customer workflow, business rules, evaluation set, data permissions, integration points, and records needed to explain a decision. The layers most often reasonable to rent are commodity infrastructure, general model capability, identity, billing, monitoring, and mature collaboration features, provided the provider meets your risk and exit requirements.
This division keeps the organization from spending scarce engineering time rebuilding capabilities that do not differentiate it. It also avoids placing essential context and control inside a vendor product that cannot be tested or exported. Write the boundary down before you choose a contract or architecture.
Workflow logic, permissions, approved sources, evaluation cases, business rules, user experience, audit records, and fallback process.
General models, infrastructure, identity services, storage, observability, payment rails, and standard collaboration features.