Skip to main content
Let's talk
Back to all posts
Automation · 2 min read

Automations that don't break: the boring stack

Fancy orchestration tools are what you add after you've built the boring foundation. Skip the foundation and you'll be paged at 3am wondering why your automation fired twice.

Written by Brayan Oduro

I’ve built dozens of integrations between SaaS tools — CRM ↔ billing, webhook ↔ database, “when X happens in service A, do Y in service B”. The pattern that’s never let me down is also the least exciting.

Three primitives, in order

If a teammate asks me how to build a new automation, the answer is always the same:

  1. Idempotency first. Every operation must be safe to retry. Derive a key from a stable input (event ID, not timestamp). Store it. Skip on collision.
  2. Retry with backoff, never silently. Failures happen. The question is whether you know about them. Surface every retry that hits its ceiling.
  3. One persistent log line per event. Not a stream of debug logs. One structured line with: event ID, source, action taken, outcome, duration. That’s your forensics layer when things go sideways at 3am.

Get those right and you can build almost anything on top.

The stack I keep coming back to

  • Webhook receiver — anything that can verify a signature in 20 lines.
  • Queue — Cloudflare Queues, BullMQ, or even a Postgres table with SELECT ... FOR UPDATE SKIP LOCKED. The choice matters less than the discipline.
  • Idempotency store — Redis with TTL of 7 days, or KV with the same. Don’t reach for a full DB row.
  • One log destination — pino + a hosted aggregator. Searchable, dated, parseable.

You’ll notice there’s no orchestrator on this list — no n8n, no Zapier, no workflow engine. That’s deliberate. n8n in particular is excellent for team-facing workflows and quick integrations between SaaS tools. But tools like these are the top layer, not the foundation. Build the primitives first, then add the orchestration on top. Skip the foundation and even a well-configured n8n workflow becomes a liability the day it runs something critical.

The mistake I keep seeing

Teams reach for a workflow engine on day one. Workflows are great when you have 50+ branching processes to maintain. Most teams have five automations that each run a couple thousand times a day. For that, code beats config — every time.

A well-typed function with three primitives baked in is more reliable, more debuggable, and (frankly) faster to ship than a six-step visual workflow that someone has to remember to maintain.

Boring stack. Fewer 3am pages.