Buy The Commodity, Build Only Your Advantage

"Build, buy, or partner" is the wrong first question, and asking it first is how AI budget ends up in the wrong column. The question that actually moves the money is narrower and less comfortable: which parts of this system are yours to own? Everything that fails that test is a purchase, a composition, or a thing that should not be built at all — and the last option is the one no vendor will ever quote you for.

A major US TV network came to ML LABS holding a quote to build a full software system for a workflow that did not require one. The scoping session is what stopped the purchase — the workflow needed a fraction of the machinery it had been priced for, and the network kept the rest of its budget. Their AI Program Manager put the number on the record:

Omar delivered in two weeks what our team estimated would take six months. The scoping session alone saved us from a $200K mistake. He operates at a level you rarely see in this industry.

ML LABS has taken more than ten heavy-workload systems to production over fifteen-plus years, across healthcare, telecom, PropTech, and finance. The rule the practice works by is the one that decision put to use: build only what is yours to own, buy what is nobody's advantage, and compose the rest from parts someone else already runs.

Ownership Decides, Not Cost

Cost is the easiest argument to have, because it is the only one that fits in a spreadsheet — and it is the wrong one. The decision that matters is whether the answer to this problem depends on data, constraints, or workflow that only you have. When it does not, a vendor's roadmap is a perfectly good roadmap and buying is the disciplined move. When it does, the integration logic is the product, and no amount of vendor configuration will produce it.

A survey on AI in the enterprise (Deloitte, 2024) finds the strongest returns come from a portfolio: commercial tools for standard capabilities, custom development for strategic ones. The durability of the custom half has a name — tight control over complementary assets (NBER, 2024) — and it is why AI produces advantage (Strategic Management Journal, 2023) only when it is built for defensibility rather than feature parity. For everything that is simply operational, the guidance is the opposite and just as firm: buy with minimal customization (HBR, 2020).

The buy case is easy to state and hard to accept, because buying feels like conceding ground. It holds whenever three things are true at once:

• The problem is well understood and generic — email classification, document processing, standard analytics — and the vendor's roadmap is a better bet than your backlog.
• Your data is an input to the tool, not the reason the tool works.
• The integration is surface-level: a widget, a dashboard, a standalone workflow with a clean edge.

Buy those quickly and put the money where bought tools hit their ceiling — every engineer-week spent rebuilding a commodity is a week not spent on the one part of the system a competitor cannot purchase.

Compose Before You Build

Between buying a product and building one, there is a third answer: assemble the thing from parts that already exist, and reserve original engineering for the part that is genuinely new. ML LABS builds and operates Izer, a presentation product in the internal portfolio at Escape Velocity Labs, a sister practice under the same owner. Its core is decks that live at a URL, and it has no comment store — comments federate to Revws, another product in the same portfolio, behind a scoped token minted per viewer. The refusal is written into Izer's codebase as a rule: we do not build comments. The companion piece on refusing to rebuild the periphery walks through the seams that decision creates.

The same line runs through client work at a far larger scale. On the cloud ECG backend ML LABS built for HeartSciences, the AI models are not ours — the platform runs inference from multiple AI model providers, and turning one on for a given organization is a configuration change rather than an engineering project. What got built is everything the models cannot do alone: multi-vendor ingestion, inference routing where every record reaches a definite terminal state, HL7 and FHIR result delivery into a major EHR vendor's system, usage-based billing. The platform was designed from the start so that onboarding a new organization is configuration, never code.

Two systems, one boundary: buy or borrow the commodity, and spend the engineering on the seams and the core. A composed system is not a cheaper system — it moves the work from building features to designing joins, and joins are real engineering — but it is a smaller system, and smaller is what ships.

Match Rigor To The Bet

The problem type tells you what to execute. Your readiness tells you how — organizational readiness (Frontiers in AI, 2025) is what decides whether an early failure becomes learning or a dead end. Put the two together and the decision stops being a debate:

A strong engineering organization still buys the commodity — building it consumes the only capacity that could have gone to the differentiator. A weak one still builds its differentiator, because nobody else can; it simply does not do it alone. Then price the diligence to the bet: a tool you can cancel at month's end, a $20K design ending in a written plan and a working spike on your own data, and a $45K production workflow build are three sizes of commitment, and total cost of ownership (Gartner, 2024) only bites on the last two.

The failures cluster in four places, and none of them is about picking the wrong vendor. Each is a decision taken at the wrong altitude:

• Building to save money. A team you have not hired is not the cheap option — it is a hiring project with an AI project attached, and AI talent is a significant investment (Stanford, 2025) either way. Build for control, never for cost.
• Buying where you needed customization. A vendor demo runs on the vendor's data. The only evaluation that binds is the one run against yours, and it belongs before the signature.
• Building without a written target. ML LABS defines measurable targets before work starts, and missing them for reasons within our control is a full refund — that is what makes a target a target rather than an aspiration.
• Deciding once. The AI Risk Management Framework (NIST, 2023) asks for continuous reassessment; a classification made when a capability was proprietary goes quietly wrong when the market commoditizes it.

Politics Fills A Strategy Vacuum

This framework needs one input it cannot supply: a leadership answer to whether a given use case is a differentiator or an operational necessity. Without that answer the decision defaults to vendor relationships, sunk political capital, or whoever argues loudest in the room — and the organization ends up building the commodity and buying the differentiator, the exact inversion. Resolve the strategy question first. No amount of AI investment compensates for strategic ambiguity.

The second input is timing. A boundary drawn at design time becomes a configuration surface; the same boundary drawn after launch becomes a rewrite, with a business already running on top of it. On the ECG platform the line was set before the build, which is why onboarding a new organization is a configuration change today rather than an engineering project.

First Steps

1. Write the ownership sentence. For your top opportunity, complete this in one line: "Only we can build this, because ___." If the blank fills with data, a constraint, or a workflow nobody else has, it is yours to own. If you cannot fill it, buy it.
2. List the seams before the features. Name every boundary your build would touch — identity, payments, comments, search, model inference — and treat each one as a composition candidate until proven otherwise. What survives that list is your actual scope.
3. Size the diligence to the bet. Before build money moves, write the target the system must hit and name the person who owns the bought-versus-built boundary. Both belong on paper, under one owner.

Classify, Compose, Then Commit

Classify every opportunity twice — once on the problem (generic, composable, or genuinely yours) and once on readiness — and let the two classifications pick the model instead of the loudest voice. Buy the commodity without apology. Compose the periphery and put the craft into the joins. Reserve original engineering for the part that carries your advantage, and write the target it must hit before anyone opens an editor.

Where the quote in front of you is larger than the problem it solves, the cheapest move is to have that problem taken apart by someone who has built systems like it before you fund the wrong one: a $750 scoping session ends in a written recommendation, and sometimes the recommendation is that the system you were about to pay for does not need to exist. If your classification already says build — proprietary problem, real integration depth, a target you can write down — the next step is a design that proves the data path before the build is priced, and the difference between a scoping call and a technical assessment covers which of those you are actually buying. If the open question is still which opportunity deserves any of this, how to find your first AI use case is where to start. Every dollar not spent rebuilding what someone else already runs is a dollar aimed at the one part of the system only you can own.

References

1. Deloitte. State of AI in the Enterprise. Deloitte Insights, 2024.
2. Azoulay, P., et al. Old Moats for New Models. NBER Working Paper, 2024.
3. Krakowski, S., et al. AI and the Changing Sources of Competitive Advantage. Strategic Management Journal, 2023.
4. Iansiti, M., & Lakhani, K. R. Competing in the Age of AI. Harvard Business Review, 2020.
5. Gelashvili-Luik, T., et al. Navigating the AI Revolution. Frontiers in Artificial Intelligence, 2025.
6. Gartner. Total Cost of Ownership. Gartner, 2024.
7. Stanford HAI. AI Index Report 2025. Stanford University, 2025.
8. NIST. AI Risk Management Framework. NIST, 2023.