The traditional build-versus-buy decision assumes a relatively stable landscape, you evaluate the options, make a choice, and live with it for years. The AI landscape doesn't work that way. The model you build on today might be obsolete in six months. The vendor you choose might pivot, get acquired, or disappear. The capabilities that seem cutting-edge now might be commoditised by next quarter.

This instability adds a third option to the traditional calculus: wrap. Build your own models, buy a platform, or wrap existing APIs with your own logic. Each has trade-offs, and the right choice depends on your specific context.

Build: Maximum Control, Maximum Cost

Building your own models means training or fine-tuning models on your data for your specific use case. This gives you maximum control over the output, the ability to optimise for your domain, and independence from vendor pricing and availability.

The cost is enormous. You need ML engineering talent (expensive and scarce), significant compute resources (expensive and ongoing), data infrastructure (complex and time-consuming to build), and ongoing maintenance as models degrade and need retraining. For most organisations, this only makes sense if AI is your core product or if you have genuinely proprietary data that creates a competitive advantage no vendor can replicate.

Buy: Fast Start, Vendor Lock-in

Buying a platform, an end-to-end AI solution from a vendor, gets you to market fastest. Someone else handles the model, the infrastructure, the updates, and the scaling. You configure it for your use case and integrate it with your systems.

The risks are vendor lock-in (your workflows become dependent on their platform), limited customisation (you get what they offer), pricing uncertainty (costs can change dramatically as the market evolves), and data privacy concerns (your data may flow through their systems in ways you can't fully control).

Wrap: The Pragmatic Middle

Wrapping means using existing model APIs, from OpenAI, Anthropic, Google, or others, and building your own application logic around them. You control the user experience, the business logic, the data flow, and the integration with your systems. The model itself is a commodity input that you can swap if a better option emerges.

This is the approach I've found most practical for most organisations. It gives you enough control to build differentiated features without the cost of building models from scratch. And it preserves optionality, if a better model comes along, you can switch without rebuilding your entire application.

The key to making wrapping work is abstraction. Build an interface between your application and the model API so that switching models requires changing the adapter, not the application. Treat the model as a dependency that will change, not a foundation that will persist.

How to Decide

The decision framework I use:

Is AI your core product? If yes, consider building. If no, probably don't.

Do you have proprietary data that creates a genuine competitive advantage? If yes, fine-tuning or building might be justified. If no, existing models are probably good enough.

How important is customisation? If you need precise control over model behaviour, building or fine-tuning makes sense. If general-purpose capabilities are sufficient, wrapping is more efficient.

What's your risk tolerance for vendor dependency? If you can't afford to be dependent on a single vendor, wrapping with abstraction layers is the safest approach.

What's your timeline? Building takes months to years. Buying takes weeks. Wrapping takes days to weeks. Match the approach to the urgency.

Planning for Change

Whatever you choose, plan for the landscape to change. The model that's best today won't be best in twelve months. The vendor that's dominant now might not be dominant in two years. The capabilities that require custom models today might be available off-the-shelf tomorrow.

This means: minimise lock-in, build abstraction layers, keep your options open, and revisit your decisions regularly. The AI landscape rewards flexibility and punishes commitment to specific implementations. Build for change, not for permanence.