This Is Not a Software Procurement Decision
Every enterprise we work with is wrestling with the same question: do we build our own LLM-powered applications or buy from a vendor? The instinct is to apply the same build-versus-buy framework they use for traditional software. That instinct is wrong.
LLM applications have characteristics that break conventional procurement logic. Here is why, and what to do about it.
Why Traditional Frameworks Fail
- The build cost is dropping faster than vendor prices. Open-source models, fine-tuning toolkits, and inference infrastructure have commoditized rapidly. What cost millions to build in 2023 can be assembled for a fraction of that today. Vendor pricing has not dropped at the same rate, which means the economic advantage of buying is eroding quarter over quarter.
- Switching costs are asymmetric. If you build on a vendor's API and they change pricing, deprecate a model, or get acquired, your migration cost is enormous. If you build internally and it does not work, you can still switch to a vendor. The optionality favors building first, because the fallback is always available in one direction but not the other.
- Data is the moat, not the model. Your competitive advantage is not in which base model you use. It is in your proprietary data and how you integrate AI into your workflows. Vendors cannot provide that integration. They can only provide the commodity layer underneath it. Paying a premium for the commodity layer while neglecting the differentiated layer is a strategic error.
When to Buy
Buy when the use case is horizontal, not core to your differentiation, and the vendor has proven scale. Customer support automation, document summarization for back-office functions, and code assistance are good candidates. These are areas where the vendor's investment in safety, reliability, and scale exceeds what you could reasonably build and maintain internally.
When to Build
Build when AI is the product or deeply integrated into your core value proposition. Build when your data is your advantage and you cannot share it with a vendor. Build when you need control over model behavior, latency, and cost at a level that API access cannot provide.
The Real Framework
Ask three questions: Is this use case core to our differentiation? Do we have proprietary data that makes a custom solution materially better? Can we staff and maintain this over three years? If you answer yes to all three, build. If you answer no to any of them, buy, or at minimum start with a vendor while you evaluate your long-term approach.
The worst outcome is spending eighteen months building what a vendor already does better. The second worst is outsourcing your competitive advantage to an API you do not control.