Build or buy AI: SaaS tool, API or custom development
When a SaaS tool is enough, when an API integration does the job, and when custom work pays for itself. A decision grid for CTOs, with what each costs to run.
6 min read
3 vendor demos are booked for next week, the CEO wants an AI plan before the board meeting, and someone on the team has already prototyped something with an API key over a weekend. The question on the table is build or buy. It is the wrong question to start with.
There are 3 options, not 2. You can buy a SaaS tool, you can call a model through an API and plug it into your own product, or you can build something custom around your data and your processes.
Buy a SaaS tool when the task is generic and internal. Integrate an API when the feature lives in your product but the intelligence is generic. Build custom when two or more of these hold: the AI is your differentiation, it runs on your own data, it runs at high volume, or it reaches deep into your systems.
Here is how we tell them apart, starting with the step most teams skip.
Write the job down first
Before comparing anything, write one paragraph: who uses it, what goes in, what comes out, how many times a day, and what happens when the answer is wrong. It takes an hour. It saves weeks of demos.
That paragraph usually answers half the question on its own. "Our sales team wants meeting summaries in the CRM" is a different problem from "our customers ask 2,000 questions a day about their contracts". The first one is probably a subscription; the second one probably is not.
The last part matters most. If a wrong answer costs a colleague 10 seconds, you can buy almost anything. If it costs a customer, a contract or a compliance issue, you need control over how the answer is produced.
When a SaaS tool is enough
Buy when the task is the same in your company as in every other one. Meeting notes, transcription, writing help, first-level ticket triage, search across a shared drive. Vendors have already built these, and a whole team improves that one feature every month.
Signs that a SaaS tool is the right call:
- the users are your own teams, not your customers
- the tool works with the software you already pay for
- nobody would notice if you switched vendor next year
- the data it touches is allowed to leave your systems under the vendor's terms
Before you sign, ask the vendor to run the tool on 50 of your real documents, not their demo set. The gap between the two is the work you will be doing in spreadsheets 6 months later.
The cost is a per-seat subscription and an afternoon of setup. The hidden cost is lock-in on workflows, not on data, so check how you get your history out before you roll it out to 200 people.
When an API integration is enough
Integrate when the feature belongs in your product or your internal tools, but the intelligence itself is generic. Summarising a document, extracting fields from an invoice, classifying an email, drafting a reply that a person checks. A model provider's API does the hard part; your code does the rest.
That "rest" is most of the work, and it is where teams underestimate the effort. The model call is a few lines. Around it you need:
- the right context sent with each request, pulled from your own systems
- a way to check the output before it reaches a user
- logs, so you can see what was asked and what came back
- a cost ceiling, because usage-based pricing grows with your traffic
- a fallback when the provider is slow or down
How long an integration like this takes depends on how deep it goes into your systems. A full custom first version takes longer: on our projects, usually 3 to 6 weeks from kick-off.
Check two things before you commit. First, where the data goes: some providers process requests in the US by default, and several now offer European hosting or deployment in your own cloud account. Second, how you will switch models later: keep the provider behind one layer of your code, so changing it is a configuration change and not a rewrite.
When custom work becomes worth it
Custom does not mean training your own model. For most companies, it means a system built around existing models: your data pipelines, your retrieval, your evaluation, your interface, your rules. It becomes worth it when 2 of these 4 things are true. One on its own is a reason to look closer, not to build.
It is your differentiation. If the feature is why customers pick you over a competitor, renting it from the same vendor your competitor uses gives the advantage away. You want to own the behaviour, the roadmap and the speed at which it improves.
Your data is the value. When the answer depends on years of internal documents, product data or client history, the work is in preparing that data, keeping it current and controlling who sees what. No off-the-shelf tool knows your permission model.
The volume changes the maths. At low volume, per-seat or per-call pricing is cheap. At high volume, the monthly bill can overtake the cost of building and running your own system. Run the numbers on next year's volume, not this month's.
The integration goes deep. A feature that reads from 3 internal systems, writes back to 2, and has to respect business rules at each step is not a plugin. It is software, and it needs to be built and maintained like the rest of your product.
A first custom version costs more upfront than an integration, then adds a monthly running cost. That running cost is the one most budgets forget.
Someone has to run it: monitor answers, update prompts and data, follow model releases, fix what drifts. Budget for that from day one, and ask any partner one question before you sign: who runs it in month 3? Most quotes stop at launch.
Our answer is the same team, staying on for monitoring, improvements and the next iteration, or a clean handover to yours.
Build vs buy AI: the decision grid
Read the table by row. The line that decides is usually "Main risk", not cost.
| SaaS tool | API integration | Custom build | |
|---|---|---|---|
| Typical use | Generic internal tasks | A feature inside your product or tools | Your core product or process |
| Time to production | Days | Depends on integration depth | First version in 3 to 6 weeks, then iterations |
| Who runs it | The vendor | Your team, light | Your team or a partner, ongoing |
| Data control | Vendor's terms | Yours, within the provider's terms | Yours: Europe, your cloud or on-premise |
| Cost shape | Per seat | Per call, grows with usage | Build cost, then running cost |
| Main risk | Misses the part that is specific to you | Underestimating the work around the call | Building what you could have bought |
Most companies end up with all three, for different jobs. The mistake is picking one answer for the whole company, usually the one the team found most interesting to build.
A sensible order is to buy for internal productivity, integrate where a feature needs to live in your product, and keep custom work for the one or two places where it changes your numbers. Start with the smallest version that reaches production, measure it, then decide whether it deserves more.
Get an outside answer before you sign
This is the question we work through in a free audit. Bring the paragraph from the first section: in one hour we go through your business, then you get a short written document that says what to buy, what to integrate, what to build, and what we advise against. Book a free audit before you sign a vendor contract or staff a project.
