Build vs buy AI: when SaaS wins, when custom wins, and the hybrid most companies end up with
I build custom software for a living, so you would expect me to say build. I do not, at least not by default. Plenty of AI problems are solved better and cheaper by a product you can buy this afternoon. The skill is knowing which problems those are, and recognizing the ones where buying locks you into someone else's idea of how your business works.
the short version
- Buy when the workflow is generic, the vendor's roadmap matches yours, and the output is not where you compete.
- Build when the workflow is how you make money, when it spans several of your systems, or when the data cannot leave your control.
- Most companies land on a hybrid: buy the model, buy commodity tools, and build the workflow layer that connects them to your data and people.
- Compare total cost of ownership over several years, including seat growth, workarounds, integration upkeep, and switching costs, not the first invoice.
01why the old build vs buy rules do not quite fit
The classic advice was simple: buy anything that is not your core competency. That still holds, but AI changes two inputs. First, the cost of building has dropped, because a small senior team with AI tooling can cover ground that used to take a room of engineers. On Pinned Golf, that approach reduced the engineering need from five engineers to one. Second, many AI products are thin wrappers around the same handful of models you can call directly. When the vendor's main asset is a prompt and a user interface, the case for paying for it every month gets weaker.
At the same time, buying has also gotten better. Mature products now cover a lot of generic work well. So the decision is less about capability and more about fit, control, and long-run cost.
02the decision matrix
Score your workflow on each row. If most of your answers land in the right column, building deserves a serious look.
| Question | Points to buy | Points to build |
|---|---|---|
| Is this how you win customers or make margin? | No, it is back office | Yes, it is the product or the edge |
| How standard is the workflow? | Same as every company in your category | Shaped by your rules, pricing, or clinical or legal judgment |
| How many of your systems does it touch? | One, with a native integration | Several, some with poor or no connectors |
| Where must the data live? | Fine in a vendor cloud | Must stay in your environment or under your controls |
| How does pricing scale? | Flat or modest as you grow | Per seat or per action, growing faster than value |
| How much do people work around the tool? | Rarely | Exports, spreadsheets, and copy-paste every day |
| Does the vendor roadmap match yours? | Yes, and you trust it | You keep waiting for features that do not come |
03when buying wins
- Generic knowledge work. Writing assistance, meeting notes, general research, and everyday chat with a model. A team plan on a mainstream assistant covers this. If you are choosing between the big two, I compared them in Claude vs ChatGPT for business.
- Mature categories. Accounting, payroll, e-signature, and email marketing tools are adding AI features faster than you could build them, and their core value is not the AI.
- Low volume. If a task happens a few times a week, the cost of building and maintaining software for it rarely pays back.
- Exploration. When you do not yet know what you need, a tool you can cancel is a cheap way to learn.
04when building wins
- The workflow is your edge. If the way you quote, triage, underwrite, or serve customers is why people pick you, encoding it in someone else's generic product flattens it.
- The work spans systems. The valuable AI work often sits between systems: read from the CRM, check the ERP, draft in the document store, update the ticket. Vendors connect to each system. Few connect them the way your process does.
- Data control matters. Regulated records, client confidential material, or contractual restrictions can rule out sending data to another vendor's platform. Building lets you choose where everything runs.
- You are paying a tax on growth. When a per-seat or per-action price grows with every hire or every transaction, owning the software can come out ahead over time.
- Customers see it. Supreme Dental did not buy a generic patient portal. It runs two native apps with an AI smile preview and an LLM assistant wired into scheduling and patient records, so patients arrive already sold on the treatment. That experience is the differentiator, which is exactly when owning it makes sense.
05the hybrid most companies land on
In practice the answer is rarely all one or the other. The pattern I recommend most often:
- Buy the model. Use a commercial large language model through an API. Do not train your own. If you need behavior the base model does not have, start with better instructions and retrieval before considering fine-tuning.
- Buy the commodities. Hosting, authentication, email delivery, payments, and the standard tools your team already likes.
- Build the workflow layer. The retrieval over your records (often RAG), the integrations between your systems, the review and approval screens, the business rules, and the testing that proves it behaves.
That layer is small compared with a full product, it is where your process actually lives, and it is portable. If a better model appears, you swap the model, not the system.
06total cost of ownership: what to actually compare
The first invoice is the least informative number in this decision. Compare these over a multi-year horizon:
| Cost driver | Buy | Build |
|---|---|---|
| Upfront | Setup, onboarding, data migration | Scoped build, ideally a fixed budget |
| Recurring license | Per seat or per usage, grows with you | None, though you pay hosting and model usage directly |
| Integration upkeep | Middleware and connectors that break when either side changes | Your code, which you maintain or pay someone to maintain |
| Workarounds | Staff hours spent filling the product's gaps | Usually lower, since the software fits the process |
| Change | Wait for the vendor or pay for customization | Change requests priced and shipped on your schedule |
| Switching | Data export, retraining, contract terms | Lower if you own code and accounts |
| Risk | Vendor price changes, acquisition, discontinued features | Builder quality and post-launch support |
The workaround line is the one buyers underestimate most. Ask the people doing the work how much of their week goes to exporting, reformatting, and re-entering data around the tool. That is a real cost, even if it never shows up on a vendor invoice.
07questions to settle before you decide
- If this vendor doubled its price or was acquired, what would we do?
- Can we export all of our data, in a usable format, at any time?
- Which parts of this workflow would we be embarrassed to have a competitor copy?
- Who on our team would own a custom system after it ships, and who supports them?
- Is there a small version we could build or buy in weeks to learn before committing?
08where Insomnia Club fits
We build the workflow layer and the products around it: custom AI development, internal tools, and customer-facing apps. We will also tell you when to buy instead. If a mainstream tool covers eighty percent of what you need and the remaining gap is not where you compete, I would rather you buy the tool and spend your budget somewhere it matters.
Where we are not the answer: if you need a general-purpose platform for hundreds of loosely related use cases, a mature enterprise suite will serve you better than a stack of custom builds. When building is right, we scope it with a fixed budget before work starts, ship every two weeks, and hand you ownership of everything.
common questions
Is it cheaper to build or buy AI software?
Buying is almost always cheaper at the start. Whether it stays cheaper depends on how per-seat or per-usage pricing grows with your company, how much manual work your team does around the tool's gaps, and what it would cost to switch later. Run the comparison over several years, not one.
When should a company build custom AI instead of buying a tool?
When the workflow is core to how you compete, when it touches several internal systems that no vendor connects well, when your data cannot leave your control, or when your team spends real hours working around a product's limits.
Does building AI mean training our own model?
Almost never. Building usually means using a commercial model through an API and writing the software around it: retrieval over your data, integrations, review screens, and testing. Training a model from scratch is rarely justified for an operating business.
What is the hybrid approach to build vs buy?
You buy the parts that are commodities, such as the model, hosting, and standard tools like email or e-signature, and you build the workflow layer that is specific to your business. That layer is where your process, data, and judgment live.
Can we start with SaaS and build later?
Yes, and it is often the right move. Buying first teaches you what you actually need. Just keep your data exportable and avoid building critical processes on features you could not replicate if the vendor changed direction.