On build vs buy
What a strong internal ML team can reproduce, and what it almost never institutionalises.
Most strong internal teams can piece together: a frontier model or an open model, a retrieval layer, an inference vendor or serving runtime, some fine-tuning code, a benchmark notebook, and a set of deployment scripts. That is not the same as owning a repeatable specialisation capability.
What internal teams almost never institutionalise
You usually do not fail because you cannot run one fine-tune. You fail because you cannot institutionalise the full loop:
- Deciding which specialist to build, with commercial intent
- Defining domain evals that are hard to game
- Converting failures into better training signal, not anecdote
- Governing promotion and rollback with evidence discipline
- Preserving provenance and accepted-state across iterations
- Operating continuously without the loop degrading when engineers are unavailable
Internal assembly can reproduce pieces of this. It is much harder to reproduce the compounding operating system around them. The work is less glamorous than the individual components. It is where the moat actually lives.
The real product is not the model. It is the discipline that makes each next model easier to build than the last.
The honest build-vs-buy question
The right question is not whether your team could assemble these pieces over eighteen months. The right question is whether they will. Whether the eval discipline will survive the next reorg. Whether the promotion gates will hold when a VP wants to ship. Whether the rollback contracts will be ready when the canary regresses.
If yes, you should build. If you are not sure, you will be paying twice: once for the build, once for the capability you eventually buy anyway.