"Build, buy, or partner" is the wrong first question, and asking it first is how budget ends up in the wrong column. The question that actually moves the money is narrower and less comfortable: which part of this is yours to own? Everything that fails that test is a purchase, an assembly of parts someone else already runs, or a thing that should not be built at all, and that last option is the one no vendor will ever quote you a price 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. A scoping session 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 it works by is the one that decision put to use: build only what is yours to own, buy what is nobody's advantage, and assemble the rest from parts that someone else already maintains.
Ownership Decides, Not Cost
Cost is the easiest argument to have, because it is the only one that fits a spreadsheet, and it is the wrong one. What matters is whether the answer to this problem depends on data, constraints, or a way of working that only you have. When it does not, a vendor's roadmap is a good roadmap and buying is the disciplined move. When it does, the logic joining the pieces together is the product, and no vendor configuration will produce it.
The buy case holds whenever all three of these are true at once:
- The problem is well understood and generic (email classification, document processing, standard analytics) and the vendor's roadmap beats your own list.
- Your data is an input to the tool, not the reason the tool itself works.
- The link is shallow: 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 week spent rebuilding a commodity is a week not spent on the one part a competitor cannot purchase.
Assemble 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.
On the cloud ECG backend built for HeartSciences, the AI models are not ML LABS's: the platform runs inference from multiple model providers, and turning one on is a configuration change, not an engineering project. What ML LABS 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. An assembled system is not cheaper; it moves the work from building features to designing joins. But it is a smaller system, and smaller is what ships.
Match The Diligence To The Bet
The problem type tells you what to do; your own readiness tells you how:
| Generic problem | Assembled from parts | Proprietary differentiator | |
|---|---|---|---|
| Low readiness | Buy commercial | Assemble with a partner | Partner to build |
| High readiness | Still buy commercial | Assemble in-house | Build in-house |
Then price the diligence to the bet. A tool you can cancel at the end of the month and a monthly engineering partnership that builds one workflow are different sizes of commitment. Running the result afterwards is its own line (ML LABS charges $10,000 a month, hands-off: monitoring, incident triage, and a review of cost and drift, with new work quoted separately), and it is the line most budgets forget until the system has started to rot.
The failures cluster in four places, and none is about picking the wrong vendor:
- Building to save money. A team you have not hired is not the cheap option; it is a hiring project with a software project attached. Build for control, never for cost.
- Buying where you needed something specific. A vendor demo runs on the vendor's data. The only evaluation that binds is one run against yours, before the signature.
- Building without a written target. The targets the system has to meet are agreed in writing before work starts, and the scope is fixed in writing at that same moment.
- Deciding once. A build-or-buy classification made back when a capability was proprietary goes quietly wrong when the market later commoditizes it.
Politics Fills A Strategy Vacuum
This framework needs one input it cannot supply: a leadership answer on whether a workflow is a differentiator or an operational necessity. Without it, the decision defaults to vendor relationships, sunk political capital, or whoever argues loudest, and the company builds the commodity and buys the differentiator. Resolve the strategy question first.
First Steps
- 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 way of working nobody else has, it is yours to own. If you cannot fill it, buy it.
- List the joins before the features. Name every boundary your build would touch (identity, payments, search, document storage, model inference) and treat each one as something to buy until proven otherwise. What survives that list is your actual scope.
- Size the diligence to the bet. Before build money moves, write the target the system must hit and name the person who owns the boundary between bought and built.
Classify, Assemble, Then Commit
Where the quote is larger than the problem it solves, the cheapest move is to have it taken apart by someone who built systems like it, before you fund the wrong one. A fifteen-minute call ends in a recommendation, and sometimes it is that the system you were about to pay for need not exist. If the open question is which workflow deserves any of this, how to find the first one is where to start. Whatever you decide to build, own it outright: a repository that transfers to you as it is paid for, code and intellectual property with it, no platform licence, and no migration project if you ever want the people who built it gone.
