Somewhere early in almost every AI project, someone asks whether to build the thing or buy it. The meeting that follows tends to be a debate about engineering capacity and vendor pricing, and it usually ends with a decision made on instinct. The problem isn't that either answer is wrong. It's that the question is framed too narrowly, and it leaves out the option that fits more real workflows than either of the other two.
The right choice depends less on the technology than on how different your workflow is from everyone else's.
Three options, not two
- Buy: an off-the-shelf product that does a defined job the same way for everyone. Fast to start, limited room to bend it to how you work.
- Configure: take an existing model or platform and shape it with your data, prompts, rules and integrations. Most of the speed of buying, most of the fit of building.
- Build: custom software around the model, owned and maintained by you. The most control, and the highest ongoing cost.
Questions that decide it
- Is this workflow a commodity? If every company in your industry does it roughly the same way, such as meeting notes or invoice capture, buying is almost always right.
- Does your advantage live in how you do it? If the process encodes judgment, data or relationships competitors don't have, that's worth owning rather than renting.
- Where does the data sit, and who is allowed to see it? A tool that can't respect your access rules isn't a shortcut, it's a future incident.
- Who will maintain it in a year? Models change, APIs change, and the person who built the first version moves on. A build without an owner is a liability.
Why configure wins more often than expected
Most business workflows are not a commodity, but they're also not unique enough to justify a ground-up build. They're a standard capability, such as summarising, classifying, drafting or extracting, applied to company-specific documents, rules and systems. That is exactly what configuration is for. You get a working version in weeks, you keep the parts that make it yours, and you can swap the underlying model when a better one arrives without rewriting everything around it.
Mistakes that make the choice expensive
- Building to feel in control, then discovering the real cost is the maintenance nobody budgeted for.
- Buying a polished demo without testing it on your own messy data first.
- Treating the decision as permanent. Start with the lightest option that works and move up only when you hit a limit you can name.
A useful rule of thumb: spend custom effort only where being different is the point, and use something standard everywhere else. The teams that get this right aren't the ones with the biggest engineering budgets. They're the ones who were honest about which parts of their workflow are genuinely theirs, and kept the decision small enough to change later.