Every quarter, some team runs the same debate: should we buy an AI tool or build our own? The debate stalls because it's framed at the wrong altitude. "AI workflow" isn't one thing — it's a stack, and each layer has a different right answer.
01The four-layer stack
- ▸Models: always buy. Foundation models are a commodity you rent by the token. Training your own is a nine-figure hobby. Even fine-tuning is usually premature before you've exhausted prompting and retrieval against your own data.
- ▸Infrastructure: mostly buy. Vector stores, orchestration frameworks, observability — mature off-the-shelf options exist. Building your own queue or eval harness is justifiable only when an off-the-shelf one demonstrably can't hold your workload.
- ▸Workflow logic: usually build. The way your proposals get written, your tickets get triaged, your candidates get screened — that's your operating DNA. Generic tools flatten it into their template. This layer is where custom pays.
- ▸Interface: build thin. Meet users where they already work — the CRM, the ticket system, Slack, email. The best interface for an internal AI workflow is often not a new app but a new column, button, or draft appearing in an old one.
02When buying wins outright
Some problems are commodity problems. If your need matches these signals, buy the tool and move on:
- ▢The workflow is genuinely standard across companies — meeting transcription, generic email drafting, calendar scheduling.
- ▢Your differentiation doesn't live in this process; nobody chooses your company because of how you take notes.
- ▢The tool's data practices pass your security review without exceptions.
- ▢You'd use under 20% of a custom build's flexibility anyway.
03When building wins
Custom earns its cost when the workflow is load-bearing and yours. The signals invert:
- ▢The process crosses multiple internal systems that no vendor integrates the way you need.
- ▢Your version of the workflow encodes judgment competitors don't have — pricing logic, qualification criteria, escalation rules.
- ▢Off-the-shelf tools would force the team to change how it works to fit the tool, instead of the reverse.
- ▢You need control over data flow, approval gates, and audit trails that SaaS defaults don't offer.
04The hybrid that actually ships
The pattern that works in practice: buy the commodity layers, build the glue and the judgment. A custom workflow that orchestrates rented models, an off-the-shelf vector store, and your existing systems of record gives you the differentiation of building at a fraction of the surface area.
This is also the pattern that survives vendor churn. When a model gets better or cheaper, you swap a config value. When a SaaS tool sunsets, your workflow logic — the part you own — doesn't go down with it.
05Worked example: the follow-up stack
Map the four layers onto the most common first build — sales call to CRM follow-up — and the pattern gets concrete. The model layer: rented, obviously; transcription and drafting are commodity capabilities you buy by the call. Infrastructure: bought — transcript storage, a queue, an off-the-shelf observability layer; nothing about your follow-ups justifies custom plumbing.
The workflow logic layer is where it flips. Which deals get a same-day draft versus a nurture cadence, what your team considers a next step, which fields your pipeline review actually reads, when a human must see the draft before it sends — that logic is your sales motion, and no horizontal tool ships it. Fifty lines of your rules do more for adoption here than any vendor feature matrix.
The interface layer: built thin, meaning no interface at all — the draft appears in the CRM activity and the rep's existing inbox. Total custom surface: the logic and the glue. Total rented: everything expensive. That ratio — judgment owned, commodity rented — is what right looks like at this altitude, and it's why the hybrid consistently beats both a pure SaaS tool and a from-scratch build.
06The question that settles most debates
When a build-vs-buy debate runs long, ask: if this workflow got 10x better, would our customers notice? If yes, it's too close to the core to rent — build the logic layer. If no, it's overhead — buy the best tool, integrate it cleanly, and spend your build budget where customers feel it.
OPERATOR NOTE — The expensive failure mode isn't building what you should have bought. It's buying five overlapping tools that each do 60% of the job, then paying people to bridge the gaps by hand forever.
Put this thinking to work.
A 30-minute strategy call with an operator — we'll map your first deployment path, not send a deck.