Engineering8 min read
How I built one automation backend to run my company
One custom automation backend now runs my entire company. I replaced Zapier, Make.com, and n8n with an event-driven FastAPI and Celery system where every new workflow is one prompt away.
Over the past few months I have been automating more and more of the processes in my company while canceling the automation tools I was paying for. Zapier, Make.com, and n8n are gone. Everything now runs through one custom backend that I built with AI coding agents, and Datalumina does over seven figures in annual revenue on it.
Two years ago building this would not have been economically viable. That math has changed, and I think every company needs to pay attention to it.
The surprising part is how little AI runs inside the system itself. AI built it. AI barely operates it.
Most automation problems are orchestration problems
Everyone is obsessing over coding harnesses right now. The latest model, building skills, which skills to use. Open YouTube as a developer and that is your entire feed. I use those tools myself, for client work and to build the exact system in this post, but the over-obsession with the process makes us forget what to build in the first place.
Look at how AI actually gets implemented in companies and you find low-hanging fruit everywhere. Simple custom software that replaces a tool. A custom script that connects two systems. Work that two years ago would never justify the build cost.
We learned this the expensive way. At Datalumina we ran a lot of LLM pilots for clients. Some were great, and a few have been running in production for three years. A lot of them failed. The technology was rarely the problem. The use case was not good enough for it. In several cases a far simpler solution, connecting two systems together with no AI at all, would have helped the client more than a three-month custom LLM pilot that ran out of budget. I wrote about that failure pattern in why AI agents don't deliver ROI. Most automation problems are orchestration problems, and orchestration needs no model.
Two types of automations run every company
Strip away the tooling and there are two kinds of automations. Work that reacts to a trigger, and work that runs on a schedule.
Trigger-based work follows events. A payment comes in through Stripe and needs to land in Airtable or the accounting system. Someone books a call through Calendly and a deal needs to appear in the CRM for a sales rep. A form gets submitted and an onboarding flow starts.
Scheduled work follows the clock. Every Monday at 9:00 a.m. someone needs a pipeline report. Every night orders sync between systems. Each company has a pile of both, and the pile only grows as companies become more AI-first and more data-driven.
The plumbing tax finally became worth paying
Automating even something simple used to require a painful amount of setup, which I call the plumbing tax. You need a server, a backend with API endpoints, and a deployment strategy so a git push goes live. Add authentication, API key management, and secure secret handling. Then the webhook endpoint itself, plus a way to test, debug, and validate all of it. Two years ago you would spend more time automating a single task than the manual work would ever cost you.
That is why Zapier, Make, and n8n won the last decade. They solved the plumbing tax. Create an account, log into Stripe and Airtable with OAuth, pick a trigger, add two or three steps in a friendly UI, and the automation is live. I ran my own company that way for years, even though I could theoretically automate everything with Python. I could not be bothered.
AI coding agents changed the economics. Paying the plumbing tax is now worth it, and you only pay it once if you set the system up properly. Even so, I kept postponing the build until a couple of months ago, when I finally committed. It has drastically changed how I run my business. The infrastructure exists now, so when I want to connect a new tool, say Calendly into Airtable next to the existing payment flow, the new workflow is one prompt away. Roughly 99% of the work is already done.
One backend the whole company connects to
Building this system changed how I think about AI transformation. Almost everything you hear about AI at work today is what I call bottom-up transformation. One person gets faster with a coding harness like Claude Code or Codex. Even when tasks run in the background, the work stays user-centric. Personal productivity goes up, and that is great.
Top-down transformation starts from the other end. Look at how the company is built. The systems, the processes, the people, and the information flowing through them. Then work that downward into automations, for some processes without a person in the loop at all. The company runs one backend, at least in the beginning, and every person and team connects to it. The key distinction is that it runs without anyone present. Triggers and schedules fire whether or not someone is at a keyboard.
A complete AI transformation needs both. I use Claude Code and Codex every day, and I am constantly offloading more of the work to the backend so it runs on its own.
Persist every event first
At the core of the system sits an event-driven architecture. Whenever something happens, the event is persisted to the database before anything else. You can see its status, whether it executed, whether it needs a retry, whether it errored. Nothing calls another system directly and waits for an answer. Workers pick the work up asynchronously, and the stored events double as a ledger you can look back into. I documented the full design in the automation backend docs.
The design is technology-agnostic, so you could build it in almost any language. I use the Python ecosystem because I am an AI engineer with a data science background. My domain runs through Cloudflare and everything deploys to one big Hetzner VPS. One server runs the whole company. Caddy handles HTTPS and only lets specific IP addresses through. FastAPI and Celery form the central layer, with a Redis queue holding the work until Celery workers pick it up. Everything persists to a Supabase Postgres database with strict IP rules. Grafana dashboards and Sentry cover monitoring and error handling, and the whole thing ships as one Docker Compose stack behind a firewall I can only reach over a VPN with a dedicated IP address.
That reads like a lot of components, and it is. All of it falls under the plumbing tax, and almost all of it was a one-time setup. For the webhook layer specifically, I broke the handler pattern down in how to build webhooks for your AI platform.
Keep going
Start with production-ready code
GenAI Launchpad is the boilerplate behind our client builds, with webhooks, schedulers, and agents wired up and ready to extend.
What one purchase kicks off
The system breaks down into six broad categories, covering intake, state, execution, integrations, operations, and delivery. The easiest way to understand them is to follow one real workflow through the system.
Our Datalumina Academy has thousands of users across free products and paid programs. When someone purchases the GenAI Accelerator on the website, the journey starts in Polar, our payment provider. Polar is configured to send a webhook for every order, and that webhook hits a file called polar.py in the API layer of the backend. The event is persisted to the database, queued in Redis, and picked up by a Celery worker that executes the workflow.
That workflow chains six deterministic steps. A normalization step cleans the payload. Drip, our email platform, tags the customer and sends the onboarding email. Circle, where we host the courses, invites the member and applies the product tag. Close, our CRM, gets a record so we can track everyone from free user to customer. Airtable logs the sale. Finally, a dedicated Slack channel notifies me that someone purchased.
The structure around this is deliberately rigid. Every workflow lives in the same folder layout with an identical schema, strict validation, and a node config that declares which node connects to which. Your AI coding agent never has to decide where to put a file or which pattern to use. We have optimized this exact structure for three years, and it sits at the core of all our client builds too.
Schedules run through the same engine
Scheduled work goes through the same workflow engine with a different entry point. One cron job, executed through Celery workers, runs every morning at 7:00 a.m. and performs a sales sync. It pulls revenue from our Data Freelancer and GenAI Accelerator programs into one Airtable dashboard so we can track the numbers on a daily and monthly basis.
That pattern quietly turns the backend into your own data platform. On a schedule, pull data from a system and push it into a visualization tool. We just use Airtable views for it.
The architecture is the secret sauce now
The workflows in this system use very little AI, and that is on purpose. Deterministic steps are what make automation reliable. AI does the heavy lifting where it belongs, in building and extending the system, guided by a structure rigid enough that a coding agent never has to improvise.
That points at the bigger shift. The code and the implementation are no longer the secret sauce. The architecture is. Once you understand the design, you can hand it to your coding agents and build it in whatever language you work in. Start with the automation backend documentation if you want the component-level breakdown, or watch the full video walkthrough to see the actual system on screen.
This backend covers the orchestration half of the picture. For the engineering discipline around it, the evals, retrieval, and monitoring that make AI systems trustworthy, start with how to build production AI systems.
FAQ
Should you replace Zapier with a custom backend?
If automation is core to how your company runs, yes, and the switch is now economically viable because AI coding agents do most of the build. The setup cost is a one-time plumbing tax. After that, each new workflow costs roughly one prompt instead of another subscription tier. For a handful of simple zaps that rarely change, the no-code tools are still fine.
What stack do you need to build an automation backend?
My stack is FastAPI for the API and webhook layer, Celery for background workers and scheduled jobs, Redis as the queue, and Supabase Postgres for persistence, all deployed as one Docker Compose stack on a Hetzner VPS. Grafana and Sentry handle monitoring and errors. The design is technology-agnostic, so you can map the same architecture onto any language.
Does an automation backend need AI?
Very little, and that is deliberate. The individual workflow steps stay deterministic because that is what makes them reliable. AI earns its keep in building and extending the system, and you can add an LLM step to a workflow when a specific task genuinely needs one.
What is the plumbing tax?
The plumbing tax is the one-time setup cost of running your own automations. A server, API endpoints, CI/CD, authentication, secret handling, webhook endpoints, and a way to test and debug it all. Tools like Zapier won the last decade by making that tax disappear. AI coding agents made it worth paying yourself, once.
What does event-driven mean in an automation backend?
Every incoming event is persisted to the database before any work happens. Nothing calls another system and waits for the answer. Workers process events asynchronously from a queue, so you get status tracking, retries, and a complete ledger of everything that ever happened in the system.
