Build vs buy automation: when to use a tool and when to build

"Should we use a tool or build it?" is the most common automation question — and the most commonly answered wrong, because people compare the wrong numbers. Here's a framework that holds up, and the total-cost math that decides it.

The three questions that decide it

Forget the sticker price for a second. Build-vs-buy comes down to:

1. How unique is the workflow? Standard (CRM → email)? Buy. Specific to how your business runs? Lean build.
2. How critical is it? Nice-to-have? Buy. Business depends on it being right and reliable? Lean build.
3. What's the total cost at your volume? Low volume favors buying; high volume favors building (no per-task fees).

Two "build" answers usually means build. Two "buy" answers usually means buy.

When buying is right

Don't build what you can buy for $20/month and forget about. Over-engineering a trivial workflow is its own mistake.

When building is right

This is where custom code you own wins — it runs at near-zero marginal cost and does exactly what you need.

The total-cost mistake

Here's the math people get wrong. They compare a tool's monthly price to a build's one-time cost and conclude buying is cheaper. But the real cost of buying includes:

• Subscription + per-task fees that climb with volume
• The hours your team spends working around the tool's limits
• The cost of silent failures (the zap that turned off and lost three days of data)

Project that over the time you'll actually run the workflow, at your real volume, and the line crosses. For a high-volume or critical workflow, a build often pays for itself in months. (See the cost breakdown for how scope drives a build's number.)

The best move: start bought, build the winners

You rarely have to choose up front. The pragmatic path:

1. Prove it with a tool — Zapier, Make, or n8n. Cheap, fast, and it teaches you exactly what the workflow needs.
2. Watch what happens — which workflows get expensive, critical, or limited?
3. Build those — rebuild the proven, valuable ones as owned code; leave the trivial ones on the tool.

Starting with a tool de-risks the build by turning unknowns into a clear spec. (This is the same arc as when to move off Zapier.)

The take

Buy for standard, low-volume, non-core workflows — value in hours, no reason to build. Build for unique, high-volume, or business-critical ones — owned code is cheaper and sturdier at scale. Judge by uniqueness, criticality, and total cost at your volume, not the sticker price. And when in doubt, start bought and build the workflows that earn it.

Want a straight answer for a specific workflow? Book a free 20-minute call — we'll tell you honestly whether to buy a tool or build it, and what a build would cost. No pitch if a tool is the right call.