The AI market encourages the belief that a perfect tool exists for every problem. Sometimes it does. But even an excellent product can fail when it does not fit the data, permissions, and habits that make an organisation distinctive.
When to buy
Buying is often sensible when the problem is common, differentiation does not depend on the specific workflow, and a product already meets the needed support, security, and integration requirements. The goal should be faster adoption, not an illusion of technical control.
When to build
Building makes sense when user experience, proprietary data, or domain logic are part of the competitive advantage. It rarely means training a model from scratch. More often it means designing the workflow, evaluation, integrations, and interface around existing models.
The useful question is not “which model is best?” It is “which system, data, and process combination creates an advantage we can sustain?”
Total cost is more than API price
Compare licences, inference, integration, observability, support, migration, lock-in, and remaining human work. A cheap tool that creates many exceptions can cost more than a system that is reliable on the actual task.
Make the choice reversible
When uncertainty is high, design a pilot that compares options on representative data. Define metrics, quality thresholds, and stop conditions before starting. The right answer today may change; the architecture should allow change without needless rewrites.