The instinct to build is healthy. Your data is sensitive, your problems feel unique, and the demos you've seen from vendors were trained on someone else's benchmark. If predictive models are going to matter to the business, owning the capability sounds like strategy.
We're a company that builds these systems for a living, so discount our view accordingly. But we've also watched the in-house version of this movie from the inside, at labs, at enterprises, at companies that got it right, and the budget that gets approved is rarely the cost that gets paid. Here is the full invoice.
The line items nobody budgets
The team is the smallest number
The plan says three to five people: an ML lead, two ML engineers, a data engineer, at $200–350K each. Call it $1.5M a year loaded. That number is real, but it's the floor, hiring them takes six months in a market where every strong ML engineer has a frontier-lab offer, and the first hire you get wrong costs you a year.
Eighty percent of the work is plumbing
The actual composition of an enterprise ML project: data access negotiations, warehouse archaeology, pipeline construction, feature stores, backfills, monitoring, serving infrastructure. The modeling, the part your hires signed up for, is the thin layer on top. This is why strong people leave these teams, and why the engineers you redirect from your product to "help with data" are the most expensive line on the invoice: they're your best people, spending years on infrastructure that creates no customer-visible value.
The first result is 6–12 months out, if the project succeeds
Industry surveys have put the failure rate of enterprise ML initiatives somewhere between half and three-quarters for years. The failures aren't usually mathematical; they're organizational, the pipeline stalls, the sponsor rotates, the model ships but never gets wired into a decision. Every month in that window is retention revenue, fraud losses, and mispriced risk that you never get back.
The second model costs almost as much as the first
This is the line that surprises boards. In the per-project world, the churn model's pipeline, features, and training setup transfer only partially to the credit-risk model. Each new question is a new campaign, new features, new labels, new validation, new serving path. The capability you thought you were buying, "now we can answer predictive questions", turns out to be "now we can start predictive projects."
Maintenance is a tax, not an event
Models decay as the business changes. Budget 20–30% of build cost per year, per model, for retraining, drift response, and pipeline repair, forever. Five models in, your team's calendar is mostly upkeep, which is also when the resumes start circulating.
You budgeted for a team. You bought a department, one whose second-best use of your best engineers is maintaining last year's pipelines.
What changed in the build-vs-buy math
The traditional rebuttal to all of the above was: "fine, but a vendor means our data leaves, and their model doesn't know our business." Both halves of that rebuttal have expired.
Deployment moved inside the perimeter. A modern enterprise foundation model trains and serves inside your own cloud, the data never crosses your boundary, the weights are yours, and your security team audits every path. "Buy" no longer means "send your data out"; it means "someone else's specialists operate inside your walls."
And the per-project structure, the thing that actually made building expensive, collapsed. One self-supervised pretraining run on your raw event history does the representation work for every downstream question at once; churn, risk, fraud, and LTV become lightweight fine-tunes measured in days. The second model, the one that costs almost as much as the first in-house, is where the foundation approach gets cheaper instead.
When building in-house is still right
Honest answer: sometimes. If ML is your product, you're a quant fund, an ads platform, a fraud vendor, the capability is your moat and you should own every layer of it. If you already have a mature ML platform team and your marginal cost of another model is genuinely low, the calculus holds. And any partner you choose should leave you more capable, not less: you should own the weights and the embeddings, so that walking away means ending a contract, not unwinding a dependency.
The checklist
Before approving the in-house plan, ask for these numbers in writing:
- Fully-loaded team cost, including the hiring timeline and one mis-hire.
- Months to the first model in production, and the revenue value of each of those months.
- Cost of the second model, estimated separately, this is where per-project economics hide.
- Annual maintenance as a percentage of build, across the whole portfolio.
- The opportunity cost: what your product engineers would have shipped instead.
- The exit cost of each path, unwinding a department versus ending a contract.
If the in-house numbers still win, build. In our experience, they win far less often than they get approved.