Build, Buy, or Glue: How to Choose an Automation Route

Every automation you need has at least three paths to it: write the code yourself, buy a product that already does it, or glue tools you already pay for into something close enough. The route you pick decides who debugs the thing at 2am, how fast you learn it broke, and how expensive it is to walk away next year. Here is the comparison, minus the vendor enthusiasm.

The three routes, and what each one really costs

Build means you own the code and the runtime. A cron job, a queue worker, a small service. You control the data model, the retries and the logs.

Buy means a product already implements the workflow. You configure it, hand over credentials, and pay a subscription or a one-time license. In exchange you get support and a changelog you did not have to write.

Glue means you connect systems you already run: an automation platform such as Zapier, Make or n8n, a webhook, a serverless function, a spreadsheet with an API. The logic lives in the connections between tools rather than in one system.

Real automations are usually hybrids. The useful question is not “which route” but “which route carries the critical path” — the part that must not fail silently.

Time to first value is not time to break-even

Buy wins the first afternoon, if the product’s default workflow matches yours. Glue wins the first hour, if trigger and destination both already exist as connectors. Build loses on day one almost every time.

The trap is treating first value as the finish line. A product that takes four hours to configure but forces your process into its data model will cost you every time the process changes. A glue chain that took an hour to wire will cost you every time a connector’s schema drifts. Neither is wrong; both are bills that arrive later.

If you can prototype the glue route in under a day, do it, even if you expect to build the real thing later. You learn the failure modes while the cost of being wrong is small.

# Prototype a glue automation with no vendor account: cron plus curl.
*/15 * * * * /usr/local/bin/glue-sync >> /var/log/glue-sync.log 2>&1

#!/usr/bin/env bash
set -euo pipefail
since=$(cat /var/lib/glue-sync/cursor 2>/dev/null || echo "")
resp=$(curl -fsS -H "Authorization: Bearer $API_TOKEN" \
  "https://api.example.com/v1/items?updated_after=${since}&limit=100")
echo "$resp" | jq -c '.[]' | while read -r item; do
  curl -fsS -X POST -H 'Content-Type: application/json' \
    -d "$item" https://hooks.example.com/ingest >/dev/null
done
echo "$resp" | jq -r '.cursor // empty' > /var/lib/glue-sync/cursor

The cursor file is the whole trick: it makes reruns idempotent, so a failed night can be replayed without double-posting. Bought tools handle this invisibly, which is convenient right up until you need to replay a window they will not replay.

Maintenance and failure visibility

The failure visibility column is the one people get wrong. Bought tools fail quietly by design: a trigger that no longer matches, a field renamed upstream, a task limit hit at 3am. Nothing errors, because nothing ran. Glue behaves the same way, except the middleware will retry and then archive the event somewhere you can find it. Build fails loudly, but only if you wrote the alert. Instrumenting an automation is not optional work you do later; triage habits for automations that fail while you sleep covers a simple loop for it.

A minimal alert wrapper is a few lines of YAML:

# .github/workflows/nightly-sync.yml
on:
  schedule: [{cron: "0 3 * * *"}]
  workflow_dispatch:
jobs:
  sync:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/sync.sh
      - if: failure()
        run: ./scripts/alert.sh "nightly-sync failed: run $GITHUB_RUN_ID"

If your automation runs inside a vendor, replicate this. Most platforms ship a notify-on-error setting that is off by default, plus a webhook for failed runs. Turn both on before you need them, and add a heartbeat check that alerts on the absence of runs, not just on errors.

Where each route locks you in

Buy locks you in through the workflow itself. Your steps live in their format, your history lives in their database, and your process quietly reshapes to fit their UI. The exit cost is reimplementing the workflow plus migrating whatever data you can export. Ask before you buy: can I pull my event history out as JSON or CSV, and does anything still work if I stop paying?

Glue locks you in through the middle layer. Zaps, scenarios and n8n workflows are not portable between platforms, and every connector is someone else’s API surface. The comfort is that each endpoint stays replaceable: you can swap the trigger without rewriting the destination, or move one hop out of the platform and into a script. If you have not chosen a platform yet, Zapier vs n8n vs AI workflow builders is the practical comparison.

Build locks you in the opposite way. No vendor can raise prices or deprecate the feature you depend on, but the system exists only as long as you maintain it and remember how it works. That is a genuine operational risk for a solo operator. The mitigations are boring and effective: keep the automation in a repository, pin dependency versions, write the runbook in the same repo, and make every step idempotent so a retry is always safe. For AI automations, add one more: keep prompts and model calls behind your own thin interface so a provider switch is a config edit rather than a rewrite. That is the core argument in context engineering.

What to do next

1. Write one sentence per automation: trigger, transformation, destination, and what happens when it fails. If you cannot write that sentence, you do not have a spec and no route will save you.
2. Time-box a glue prototype before you build or buy. One day, one script, real data, real failure. Bash plus cron is enough to learn whether the API is honest about pagination and rate limits.
3. Turn on failure notifications before launch, not after. One channel, one alert per failed run, with a run ID you can search for, plus a heartbeat that fires when runs stop happening.
4. Price the exit. Estimate the hours to migrate off the vendor, or the hours to hand your script to another person. Compare that number against the cost of leaving things as they are.
5. If the answer is build and the domain is AI plumbing, the AI Developer Stack Bundle is $79 one-time and includes a prompt library, agent framework, deployment tooling and tutorials that come pre-configured to work together, which shortens the parts that are not your actual product.

Get AI Developer Stack Bundle

AI Developer Stack Bundle — $79, one-time payment, instant download. See the full breakdown on the review page.

Related reading

• The Ultimate Guide to AI Automation 2026
• How I Built a 10-Product Digital Business
• Building an AI Content Factory