The short answer
Most companies should default to buying wherever a decent tool already exists, and reserve custom building for the smaller set of workflows that are genuinely specific to how they operate. If your process looks like every other company's in your industry, a tool already exists for it, and building your own version rarely earns back what it costs. If the process is unusual, spans several systems that were never designed to talk to each other, or is close to the thing your business is actually good at, custom software tends to pay for itself over time.
Neither answer is permanent. The right call for a five-person team is often the wrong one for the same team at fifty people, and it's worth revisiting as volume, complexity, and internal capability change — which is exactly the kind of question an AI strategy engagement is built to answer across a whole list of candidate projects rather than one at a time.
The decision framework: six questions to ask before either
None of these questions decides the answer alone. Weigh them together against the specific workflow, not against AI as a category.
- How differentiated is the workflow? A process that works the same way at every company in your industry is a commodity workflow, and commodity workflows are exactly what off-the-shelf tools are built to handle well. A process built around rules, exceptions, and judgment calls specific to how you operate is a different case — the differentiation is often the thing worth protecting.
- How many systems does it span? A workflow that lives inside one tool is usually a configuration problem, not a build problem. A workflow that has to read from a CRM, check inventory, update a scheduling system, and notify a delivery partner is an integration problem, and integration depth is where packaged tools run out of road fastest.
- How much does the vendor's roadmap matter to you? Buying a tool means adopting someone else's priorities. If the feature you need is on their roadmap, you wait for it. If it's not, you don't get it. For a workflow that isn't strategic to you, that trade is fine. For one that is, it's a real constraint.
- What do switching costs look like later? Some tools are easy to leave — export your data, cancel, move on. Others quietly become the system everyone's process depends on, and leaving means rebuilding years of configuration and institutional habit. Ask what leaving costs before you're locked into paying it.
- How much compliance exposure is involved? Workflows touching regulated data — health records, financial details, anything covered by data protection law — need clear answers about where data lives, who can see it, and how long it's kept. A vendor may or may not give you those answers in the form your compliance function needs. A custom build gives you direct control over all of it, at the cost of being the one responsible for getting it right.
- Do you have the internal capacity to run what you build? Custom software doesn't run itself once it's live. Someone has to own it, notice when it needs adjusting, and make small decisions about how it evolves. If nobody on your side can do that — or you don't want anyone to have to — that's a real point in favor of buying, not a gap to paper over. The AI readiness checklist goes deeper on what that capacity actually looks like before a project starts.
Buy vs. build, side by side
| Dimension | Buy (off-the-shelf) | Build (custom) |
|---|---|---|
| Time to value | Days to a few weeks — sign up and configure | Weeks to a few months, scoped before work starts |
| Upfront cost | Low — a subscription, little to no engineering spend | Higher — design and build work before anything ships |
| Running cost | Predictable subscription that scales with seats or usage | Ongoing maintenance and hosting, but no per-seat tax as you grow |
| Control | Limited to what the vendor chooses to expose | Full control over logic, edge cases, and failure handling |
| Integration depth | As deep as the vendor's official connectors reach | As deep as your systems allow, including the awkward legacy ones |
| Lock-in | Your process lives inside their product and roadmap | The system and the logic inside it belong to you |
No row on this table is automatically a win for either side. A subscription's low upfront cost is a genuine advantage if the workflow is small and standard. A custom build's higher upfront cost is irrelevant if the alternative doesn't actually do the job.
When buying is clearly the right call
Buying wins more often than build-first advice admits, and there's no credibility in pretending otherwise. Choose an existing tool when most of these are true:
- The workflow is a commodity. Email marketing, standard helpdesk ticketing, basic bookkeeping, generic scheduling — thousands of companies need the same thing, and mature products already do it well.
- Volume is small. If a task happens a handful of times a month, no build pays for itself against the alternative of a person doing it directly or a cheap tool handling it.
- Integrations are ordinary. If the systems involved are common ones with well-supported connectors already, you're not fighting the kind of integration depth that justifies a build.
- Nobody internally can own it. Custom software needs a person on your side who understands it well enough to make small calls without escalating every one. If that person doesn't exist and won't soon, buying removes that dependency entirely.
- A tool already fits almost exactly. Sometimes the honest answer, after looking closely, is that the product already does nearly everything you need, and the remaining gap isn't worth a build to close. Take that answer when it's the true one.
If several of these apply, stop evaluating vendors' AI features and just pick the tool that fits the job. The guide to when not to use AI at all covers the related case — workflows where the honest answer is neither buy nor build, because automation isn't the fix the problem needs.
When building wins
The case for a custom build gets stronger as more of these stack up:
- The workflow is genuinely differentiated. If how you handle it is part of why customers pick you over a competitor, putting that logic inside a shared product is putting your edge inside somebody else's roadmap.
- It spans several systems with no shared off-the-shelf answer. The more tools a process touches, the less likely any single vendor covers the whole path — and stitching together three point tools often costs more, in money and fragility, than one system built to do it directly. This is where a purpose-built AI agent usually earns its cost: reading from one system, deciding, and writing back to another, end to end.
- Volume is high enough that small inefficiencies compound. A process that runs forty times a day turns a five-minute inefficiency into hours of lost time every week — and a tool's generic version of the workflow is rarely the fastest version of it for your specific case.
- You need exact control over failure behavior. When a workflow touches customers or money, what happens when something goes wrong matters as much as what happens when it goes right. Off- the-shelf tools give you their default; a custom build gives you exactly the boundary you decide on.
- Vendor risk is unacceptable. If the tool being discontinued, re-priced, or redirected by an acquisition would seriously disrupt the business, owning the system removes that exposure.
The hybrid answer most companies land on
In practice, the honest recommendation for most businesses isn't purely one or the other — it's buying the commodity layers and building only the part that's genuinely theirs. Keep the CRM, the calendar, the payment processor, and the ticketing system as bought tools; they're commodity infrastructure and reinventing them wastes money that should go toward the part of the workflow that actually differentiates you.
What often makes sense to build is the layer that sits on top of those tools — the logic that decides what happens next, moves information between them, and applies the judgment specific to how your business runs. That's usually a thin, custom layer rather than a full platform: an agent or workflow that reads from the systems you already bought and use every day, rather than a replacement for any of them. Buying the parts that are the same everywhere and building the part that isn't is usually cheaper, faster to ship, and lower-risk than either extreme applied across the board.
A checklist you can run this week
Work through this against one specific workflow — not "AI" as a category, one real process:
- Write the workflow down in one sentence. If it reads like a generic business function, start by shortlisting existing tools before you scope anything custom.
- Count the systems it has to touch. One or two, ordinary ones: lean toward buying. Three or more, including anything unusual: lean toward building.
- Ask whether this workflow is part of why customers choose you. If yes, be cautious about putting it inside a shared product you don't control.
- Estimate how often it happens. Occasional and low-stakes points to buying; frequent and compounding points to building.
- Name the person on your team who would own a custom system day to day. If no one comes to mind, that's a real answer, not a gap to solve later.
- Check what leaving a vendor would cost in a year, not just what joining costs today.
- Note any regulated data involved, and whether a vendor's standard answer on data handling is actually good enough for your compliance obligations.
- If the answer is still unclear after all of that, treat it as a strategy question rather than a build-or-buy guess — that's exactly the gap an audit is meant to close.