Buy, Build, or Pre-Fab: A Third Path Out of the Enterprise AI Conundrum

Every enterprise weighing a serious AI or ML initiative ends up at the same fork: buy a vendor platform, or build it in-house. Both paths look reasonable on a slide. Both, in practice, quietly burn quarters.

There is a third path emerging — one that most procurement teams haven't put a name to yet — and it is changing how serious teams get their first production model into the world. Call it pre-fab: a packaged, opinionated project scaffold, delivered as code you own, that bypasses the cold-start problem without surrendering control of how the system materializes.

The buy-side tax: a sales cycle disguised as a decision

Buying a platform sounds fast until you actually buy one. The honest timeline runs: discovery calls, technical deep-dives, security review, legal redlines, procurement, a paid pilot, a steering committee, an executive sign-off, and finally — six to nine months later — a contract. Then the integration work starts. Then the per-seat or per-prediction meter starts running, and every future change request becomes a ticket against a vendor's roadmap rather than a pull request against your repo.

The platform isn't the problem. The shape of the relationship is. You are renting opinions you didn't write, on a schedule you don't control, in exchange for a guarantee that you will never deeply understand the system carrying the decision.

The build-side tax: hero engineering and the cold start

Building in-house promises control and ends up concentrating it. The first model that makes it to production almost always rides on the back of one or two unusually talented engineers or analysts who held the architecture in their heads, made the right defaults, and glued the pipelines together over too many late nights. When they leave — or get pulled onto the next priority — the system becomes a piece of folklore.

Compounding this is the cold start: the first project pays for the entire scaffolding. Repos, CI, feature stores, evaluation harnesses, monitoring, model registries, deployment patterns, on-call playbooks. None of this exists yet, and all of it has to be invented before the first prediction ships. Six months in, the team has a beautiful platform and no model on it. Twelve months in, the model is live and the org has lost patience.

A third paradigm: buy the pre-fab, build the project

A pre-fab project is not a platform and not a vendor product. It is a complete, opinionated project — repository, pipelines, baselines, evaluation, monitoring, documentation, and the governance hooks — handed over as code your team owns from day one. The cold-start work is already done. The hero dependency is dissolved into a structure anyone on the team can read.

Crucially, the pre-fab doesn't pick the technology fight for you. The architectures, the model families, the cloud — these are largely the same ones a strong in-house team would have chosen on month nine of a build. The pre-fab's value is not exotic technology. It is arrival: you start at month nine instead of month one.

The economics: incremental earliness pays for it

The financial case for pre-fab is rarely about cost-down on the engineering itself. It is about the value of the months you don't spend cold-starting. A use case that earns even modest weekly value — fraud caught earlier, churn intercepted sooner, a pricing decision made on this quarter's data instead of last year's — compounds quickly. Three to six months of earlier time-to-market will, in most enterprises we work with, cover the entire cost of the pre-fab on its own, before the system has had a chance to improve at all.

And because the pre-fab is code you own, the second project is dramatically cheaper than the first. The scaffolding amortizes across the portfolio in a way a SaaS subscription never will.

What pre-fab is not

• Not a black box. Every layer is inspectable, modifiable, and yours to fork. If a vendor disappears tomorrow, nothing changes for you on Monday morning.
• Not a template repo. Templates give you a directory layout. A pre-fab project gives you working pipelines, real evaluation harnesses, and the operational bones a regulator or an SRE would actually accept.
• Not a substitute for judgment. The framing of the problem, the choice of target, the definition of success — these still belong to your team. Pre-fab eliminates plumbing, not thinking.

When pre-fab is the wrong answer

If the use case is genuinely novel — a research-grade problem with no precedent in your industry — pre-fab will constrain more than it enables. If the organization has already paid the cold-start tax and runs a mature ML platform with a deep bench, the marginal value of pre-fab collapses. And if the buying motion is purely about offloading accountability to a vendor, pre-fab won't satisfy that political need either.

For everyone else — which is most enterprises shipping their first serious model, or their tenth without a coherent platform — the choice has quietly become three-way.

The Forli view

We have built and rebuilt the same scaffolding enough times to know what belongs in the pre-fab and what doesn't. Crosswalk is the embodiment of that view: a pre-fabricated project you own, that arrives with the boring, expensive, easy-to-get-wrong layers already built — so your team can spend month one on the decision the model is actually meant to improve, not on the registry it will eventually live in.

Buy is slow. Build is heroic. Pre-fab is what you do when you want the control of build and the speed of buy, and you'd rather not pay for either tax.