Most "automation tool" articles compare features. This one compares scars. We deployed automation across 8 venture lines, rebuilt the stack twice, and learned more from the deployments that failed than the ones that worked. Here is the stack we run today, why each tool is in it, and which ones we removed and never replaced.
No invented dollar savings. No round-number dashboards. Just the real list.
Key Takeaway
Automation tools sit on a control-versus-convenience spectrum, and every choice trades one for the other. Convenience tools (Zapier, Make) win for low-stakes, low-volume workflows. Control tools (n8n self-hosted, custom scripts) win once volume or sensitivity crosses a line. The mistake almost everyone makes is using convenience tools for control problems. It works until it does not. Then it fails at 2 AM on a Saturday.
The Problem
The "no-code revolution" produced a new kind of technical debt: workflows nobody understands, built by people who left, running processes nobody remembers approving. We have inherited those workflows in partner ventures and we have built them ourselves. Both feel cheap to add and expensive to inventory.
There is no single answer. The honest answer is: pick the right tool per workflow, document the why, and audit monthly. Below is how we make that pick across 8 venture lines.
The Framework
01 — The Three-Layer Architecture
What we look for:
| Layer | Purpose | Tools we use | Right when |
|---|---|---|---|
| Layer 3: Convenience | Quick wins, low stakes | Zapier, Make | Low volume, non-sensitive data |
| Layer 2: Orchestration | Business-critical workflows | n8n (self-hosted), Pipedream | Needs version control + error handling |
| Layer 1: Infrastructure | Core systems, high volume | PM2-supervised cron + Node/Python scripts | Compliance + high run frequency |
Why it matters: A workflow handling payment processing for a venture should not run on someone else''s infrastructure with no audit logs and no version control. A Slack notification on form submit absolutely should. The mistake is using the same layer for both.
02 — The Stack We Actually Run
Production-grade tools running across HavenWizards ventures right now:
| Job | Tool | Why we picked it |
|---|---|---|
| Voice generation | edge-tts (Microsoft Neural) | Replaced F5-TTS after the latter took more than seven minutes of CPU to generate four seconds of speech on our droplet |
| Workflow orchestration | n8n (self-hosted) | Per-task fees on managed alternatives compound brutally past a few hundred runs/mo |
| Asset CDN | Cloudflare R2 | Egress-free vs S3 was a measurable monthly delta on video files |
| Process supervisor | PM2 | Cron + auto-restart + log rotation in one binary |
| Stock photography | Pexels API | Pre-cleared license, programmatic, no monthly minimum |
| Database + auth | Supabase | Postgres + row-level security + auth in one bill, not five |
| Programmatic video | Remotion + ffmpeg | React-to-MP4 beat every template-based video tool we tested |
Why it matters: The stack got smaller after each rebuild. Two enterprise platforms that promised to "unify everything" lost on workflow specificity. Focused tools, owned where it matters, rented where it does not.
03 — What We Removed and Never Replaced
What we look for:
- Tools used by fewer than three workflows
- Tools whose pricing model penalizes scaling
- Tools whose vendor changed pricing more than once in twelve months
Why it matters: The "could not use it without [tool]" feeling is usually a story we tell ourselves. We removed observability tooling, two analytics platforms, and an enterprise integration suite. Each one was in the stack because someone evaluated tools and forgot to evaluate whether the workflows actually needed them. Audits work.
Implementation Checklist
- Inventory every active automation across your business this week
- Tag each one with its layer (Convenience / Orchestration / Infrastructure)
- Identify any Layer 1 work running on a Layer 3 tool
- Set a 30-day deletion rule: any automation that has not run in 30 days gets deleted, not preserved
- Owner + purpose statement attached to every active automation; missing one = deletion candidate
What This Produces
- A stack that scales linearly (or sublinearly) with workflow count
- Faster forensic recovery when something breaks (the layer tells you where to look first)
- A shorter "tools-we-pay-for" list at the end of every quarter
Common Mistakes
- Layer-3 thinking on Layer-1 problems. Convenient until it is not. The 2 AM Saturday failure is not a tool failure; it is a layer-classification failure.
- Not deleting unused automations. Every workflow that exists adds inventory cost. Deletion is free.
- Building inside whatever tool the team already opens. Pick by layer, not by familiarity. Marketing should not be running payment integrations through a marketing-ops tool.
Next Steps
To see how we deploy this stack across our ventures, explore the venture portfolio. To evaluate your own automation readiness, start with our free training on execution systems.
Arena-forged across 8 venture lines. Every tool above is running in production today. See Bayanihan Harvest for the proof.