Situation
An automation agency running on spreadsheets and browser tabs
An agency that automates other companies' operations has no excuse for running its own out of spreadsheets. For a while, we did anyway. Revenue in one place, campaign state in another, workflow results in a third, and the true picture of the business assembled by hand whenever someone needed it.
That is the same disease we diagnose in clients, and it has the same cost: hours of assembly work around minutes of judgment, decisions made on stale numbers, and operational knowledge living in whoever last looked. So we treated ourselves as a client. The result matters to anyone evaluating us for one reason. The architecture we sell is the architecture we trust our own books to.
What we built
One dashboard, ten surfaces, 50+ scripts underneath
One dashboard at the center of the agency, with ten operating surfaces: a KPI overview, finances with P&L and invoices, team management, a client overview, the lead database, campaign tracking, workflow run history, workflow templates, the job-sourcing pipeline, and settings.
Under the dashboard sits the execution layer, 50+ Python scripts in production covering lead generation, email enrichment, reply detection, AI strategy and deck generation, spreadsheet operations and self-healing utilities. The scripts run on Railway behind a webhook layer, so a campaign event or a schedule can trigger work without anyone at a keyboard, and every run lands back in the dashboard as inspectable history with logs.
The financial surfaces read from the same database the automation writes to. Revenue, costs and client state are not assembled for meetings. They are current.
How it runs
Directives, orchestration, execution
Everything in this build runs on the three-layer architecture we ship to clients, which we call DOE. Directives are plain-text SOPs that define what should happen: how leads are scraped, how replies are handled, how proposals are generated. Orchestration is an AI agent that reads those directives, makes decisions, and routes work. Execution is deterministic Python, one script per job, doing the API calls and data processing.
The reasoning is arithmetic. An agent that is 90 percent reliable per step is 59 percent reliable across five chained steps. Push the steps into deterministic code and the agent only makes decisions, not mistakes of execution. The agent layer stays thin on purpose. The 50+ scripts below it are boring, testable and correct, which is what you want from the layer that touches money and outreach.
Next.js runs the dashboard, the same App Router architecture as our client platforms. Supabase is the operational database: users, clients, payments, expenses, leads, campaigns, runs. Railway runs the Python serverlessly, with the webhook layer that turns events into work. Claude sits at the orchestration layer, reading directives and routing work. Tool-by-tool reasoning is at /stack.
Four decisions keep it reliable. One database, one truth: every script writes its results back to the store the dashboard reads, so there is no synchronization step. Scripts over prompts for anything that must be right: financial math, API pagination and retry logic are deterministic code, and the model layer writes strategy and prose, never ledger rows. Every run leaves a trail, recorded with status and logs, so when something fails the question is which run and which line. And strict isolation from client data: this system runs the agency, client systems run on their own isolated instances, and the two never mix. The internal dashboard can see that a client engagement is healthy. It cannot see into the client's data.
The build paid for itself in assembly work nobody does anymore, but the durable lesson is about ownership. Because the behavior lives in plain-text directives, changing how the agency operates is an edit. A new lead source is a directive and a script. A new report is a surface over data that already exists. That experience is why every client engagement includes education on the same architecture. We are teaching clients the operating system we run on, with our own P&L as the proof.
The pattern is productized as the operations hub. The sales side of this system is the reply-to-deck pipeline, and its memory is the knowledge vault. For the client-facing version of an operations build, see the five-system build for a design firm. To find out what an operations layer would reclaim in your business, start with the free audit.