Building a content and automation system that one person can run

01What was the problem this had to solve?

There was no single problem. Four tracks ran over four months, each from its own complaint: nobody could see inside an estate that grew from 63 workflows to 102, buyers of one product were logged in and locked out, information was handed over verbally instead of filed, and content production had no repeatable shape.

The subject runs its whole operation inside one marketing platform account: courses, memberships, a paid virtual event, payments and a customer community. Every entitlement is granted by automation rather than by the purchase itself, and there is exactly one system of record to break.

people pay for it but are logged in and greyed outreported by the operations team

• The operations app. A two-person team had no shared place for tasks, decks, files or a launch board.
• The audit toolchain. Seeing the steps inside a workflow meant scrolling the builder, one workflow at a time.
• Live automation. Support requests, a webinar intake process, and the fields, tags and emails underneath them.
• Documents. Audits, checklists, procedures, a training library and a handover, generated rather than typed.

02Why reverse-engineering an undocumented API was the cheap path

GoHighLevel publishes no API for the step structure inside a workflow, so the supported way to answer a structural question about 81 workflows was to open each one in the builder and scroll. A Python script of roughly 370 lines, talking to the platform's own internal endpoints, reads all 81 in about two minutes.

An hour of clicking answers one question on one day. Two days of reverse engineering answers every structural question for the rest of the engagement, and ports to any other account by swapping credentials.

1. A stored refresh token is exchanged for a short-lived id token. It expires after about an hour, which is why early runs died partway through until the refresh was built in.
2. That token authorises a call for one workflow, and the step chain is already inline in the response.
3. The chain is rebuilt locally by sorting on an order field and following a next pointer, then written to JSON. Every later question is answered from those files.

GET /workflow/{locationId}/{workflowId}      -> 200, steps inline
GET /workflows/{workflowId}?locationId=...   -> 404, every variant

03The stack, and why each piece is there

The internal operations app is React 19, Vite, TypeScript, Tailwind CSS v4 and React Router over Supabase, deployed to Vercel, at 76 commits and 28 source files. The audit and automation layer is Python and Node.js scripts against GoHighLevel, with Playwright for the things only a real browser can confirm.

The automation layer is the platform itself rather than a service bolted beside it. A form starts a workflow, the workflow writes contact fields, a router assigns an owner, an opportunity lands on a dedicated pipeline, and each of five stages carries its own sequence. One non-obvious detail: a stage-change trigger must be filtered by pipeline, or it fires on every pipeline in the account.

Named, considered and rejected

• Firebase for the app data, because the task, project and assignee relationships needed joins.
• Airtable as the content database, on its free-plan record and automation caps and, more decisively, because it is a new tool for the team to learn.
• n8n and Zapier for the first phase, because nothing in the design needed a service the business was not already paying for.
• A transcription vendor's API, because it was early access and credit metered, and an early-access API breaks quietly.
• A custom API build for the content system, rejected outright. That argument has its own section below.

04How the work was actually split between a person and the AI

Claude Code wrote almost all of the script code, the report generators and the app features. What it could not do was decide where to look, and the most expensive mistake of the engagement was two hours of confident, well-formed searching in the wrong place that a person had to stop.

• Written by the AI: the crawlers, the report generators, the app features, the find-and-replace maps, and every document template.
• Specified by a person: what question was being asked, which account was safe to ask it in, what counts as evidence, and when to stop.
• Verified by a person: every write, by re-reading state rather than the response code. Every visual claim, by screenshot.

Turning a bespoke account into a reusable onboarding template meant genericising 52 email bodies and 14 workflows. Eight parallel agents each built a find-and-replace map for a slice of the emails, and the maps were applied centrally in one pass. Fanning out the reading is safe. Fanning out the writing is how two agents overwrite each other.

The durable artifact is not any one script. It is the written instruction file in the project, corrected every time something surprises us, whose most useful line reads: trust the user's screenshot over my synthetic test results.

05What went wrong

None of the four failures worth recording were syntax errors. An identifier match that should have found a workflow returned zero hits across all 81, a write returned 200 with an id and silently did nothing, a scroll-reveal effect hid 54 blocks of a finished client document permanently, and a hand-rolled validator reported a bug that did not exist.

• PostgreSQL has no create-policy-if-not-exists form, so a migration that reads fine fails on rerun.
• An upload reported success and displayed nothing, because an automatic join returned empty when the foreign key pointed at the auth table rather than the profiles table.
• Serialising an object to run a string replace escapes the literal quotes inside quoted copy, so plain find strings quietly stop matching.
• An ampersand is stored as an HTML entity where a trademark symbol and curly quotes are stored literally, so a find string built from what is on screen misses.
• A validator written inline in a shell string reported 14 open tags against 212 closing ones, because an escape sequence collapsed inside double quotes.
• A client document went out dated three days early, because the date came from a token claim printed by the script rather than the system clock.

06How a paying customer can be logged in and locked out

Buying granted nothing on its own. Access was tag and workflow driven, the granting workflow watched one product identifier, and the same product also sold through a second path charging a near-duplicate product with an identical name and nothing watching it. Order data settled it: 668 orders through the first path granted access and 29 through the second did not.

The part worth copying is the correction inside it. The first pass reported nineteen members stuck, having checked one granting tag. Re-checking every granting tag showed twenty-four of twenty-five already carried one, and exactly one was genuinely without a grant.

07The audit finding that was nearly a deletion

A ring-fence audit flagged 8 items sitting in the wrong account, 7 tags and 1 custom value, and the first draft of the plan had them deleted that week. They were live production assets belonging to 6 paying subscribers of a second product that was mid-migration, and deleting them would have broken those customers.

The audit was right about the facts and wrong about the frame. It labelled the assets contamination, which is the correct word if the job is a fresh build. The job was a migration, and no tooling could have caught that, because nothing in the data says whether one has finished.

• The cleanup moved behind a hard gate, so it can only run once a parallel run has proved the new account works.
• A migration phase with its own eight tasks was added, because what had been missing was a phase rather than a checkbox.
• A do-not-touch rule was pinned in bold at the top of the launch board's blockers panel, where the person doing the work would see it, not filed in a document nobody opens mid-task.

08How does the system decide what to publish, and what to hold?

Nothing reaches an audience without passing two gates. Every idea is routed through a written brief that a person approves before anything is produced, and every finished draft is checked against a rules list taken from the business's own written standards, with the judgement calls escalated to a person rather than decided by the machine.

1. Harvest. Problems from support requests, event questions, community posts and call notes land in one sheet of six columns, including who said it. There is no second database.
2. Lens. An assistant project holds the written framework as its knowledge and turns one problem into a brief. The order is load-bearing: frame first, then lens, then write.
3. The output is a brief, not content. One paragraph naming the problem, the frame, the angle and the bucket. That is what a person approves.
4. Route. One approved brief becomes exactly one of four formats. The fourth was flagged as a gap in the source framework rather than invented.
5. Check. Every draft is measured against a hard-rules list before a person reads it.

The approval gate is deliberately a setting rather than a policy: weekly batch, approve nothing, or approve everything are all legitimate, and it defaults to the weekly batch. A gate whose strictness cannot be changed gets routed around within a month.

The rules list was not written for this project. It was already in the business's own material as a page of hard rules about how copy may be written, most of it mechanically checkable, and it even named a tell that gives away machine-written copy. Enforcing an existing standard beats authoring a new one and asking somebody to adopt it.

09What stays manual on purpose, and why

Three things stay manual by design: posting short vertical video, the finishing edit, and approving every brief. Short-form goes out by hand because the platform's own social planner carries no music library, and trending audio is a primary reach driver on short video, so routing reels through it would trade reach for tidiness.

That is a platform limit rather than a preference, and it forced distribution to split rather than run as one pipe. Long-form posts, carousels and short text go out through the scheduler. Reels are posted natively. A podcast has no path through the platform, and personal profiles have none either, because the underlying social API only supports pages.

• The finishing edit. One person, four output types, more than half a dozen accounts. That is the throughput bottleneck of the whole system, and the design names it instead of hiding it behind an arrow.
• Approving the brief. The cheapest place to reject a piece of content is before anybody records it.
• Folder renames, funnel page copies and a few template fields. No endpoint exists for any of them, so they were handed back as an explicit manual list rather than half-automated into something unreliable.

One chore nobody plans for is written into the plan: social connection tokens expire and drop quietly, and a scheduler with a dead connection looks like one with nothing queued.

10Why the final deliverable argued against building software

The content production system shipped as an architecture document with no code in it, recommending against building the software that had been asked for. The argument was never about money, because at that volume the API calls would have cost close to nothing. What a custom build adds is one person in the critical path of every piece of content the business makes.

Cost is not the reason to avoid the API. Fragility is. An API build puts me in the critical path of every piece of content they make.from the architecture document

Two findings made that obvious rather than brave. The first was the brief, whose stated constraints were not about capability at all, and one of which arrived three separate times.

Keep costs low, if we do not have to use anything new let us stick with what we have. Keep it as simple and fool proof as possible. I am looking for simplicity.the brief, condensed from three messages

A custom build satisfies none of that. It adds a service to maintain, credentials to rotate, an error path nobody on the team can read, and a dependency on one contractor who will not always be there. A shared sheet, an assistant project with the framework loaded into it, and a rules check the writer runs on their own draft satisfy all of it, and every piece is already paid for and already understood.

The second finding flipped the premise of the whole track. The plan had been to extract the content framework out of the founder's head over a month of interviews. A read-only crawl found it already written down in full, as downloadable PDFs inside their own funnel pages, in two generations of 13 and 17 pages, and nobody had mentioned either existed. That turned a month of authoring into about a week of wiring, and it is the strongest argument here for auditing what a client already has before quoting to build them anything.

No code is not the same as no system. The design still has one database of ideas, a defined order of operations, a brief format, an approval gate, an automated rules check and a split distribution layer. What it does not have is anything that can break at two in the morning in a way only its author can fix. The 30 to 42 hour estimate attached to it is for wiring and writing, not engineering.

11What four months actually produced

Four tracks of verifiable output: an operations app at 76 commits and 28 source files, a read-only toolchain that reads 102 workflows in one pass, live automation on the production account, and 38 client PDFs and 16 standalone HTML deliverables generated from 77 Python scripts.

• The app. 76 commits, 28 source files, 6 tables and 5 routes at launch, 11 feature areas at the end, on Supabase and Vercel.
• The tooling. 81 workflows read in about two minutes by roughly 370 lines of Python, growing to a crawl of 102 workflows and 139 workflow email bodies.
• The automation. A support pipeline of 5 stages, 8 tags, 13 custom fields and 4 drag-and-drop email templates, plus a 28-field intake form carrying 23 new custom fields.
• The template. 52 email bodies and 14 workflows rewritten to placeholders in a demo account, using 8 parallel agents to build the maps.
• The documents. 38 PDFs and 16 HTML deliverables, a training library of 32 video cards across 9 sections that took 16 rounds of curation, and a handover of 21 pages and 25 owner-tagged open items.

12What I would do differently

Three things, and all of them are about the order the questions get asked in rather than about code: check whether the process being automated is already written down before extracting it from anybody, settle fresh build against migration before writing a plan, and stop a search that has been wrong for an hour instead of trying the sixteenth path.

• Audit what the client already has, first. A month of planned interviewing turned out to be about a week of wiring. That check costs an afternoon and should be the first afternoon.
• Time-box a failing search. When several plausible paths have failed the same way, the assumption underneath them is the thing to test.
• Wait for the walkthrough before writing somebody else's process down. A procedure written from source material was structurally wrong until an hour with the person who runs it, including two figures introduced during a reformat that had never existed.
• Verify a write by re-reading the state, not by reading a response code that was 200 with an identifier on every call that silently did nothing.

Almost none of the hard problems were coding problems. They were questions about which system holds the truth, which account is safe to ask in, and whether the thing being requested is the thing that should be built. Working with Claude Code moves the cost of an engagement from typing to deciding, and the most valuable deliverable here contains no code at all.

14Related reading

• the from-scratch marketing website build

  The companion case study covers the opposite kind of job: the from-scratch marketing website build, where nothing existed to audit and every decision was made in code rather than inside somebody else's platform.

• who built this

  This engagement was run by one person, and who built this, the credentials behind it and the rest of the work are on the about page.

• what an engagement costs

  Audits, automation builds and tooling are quoted differently, and what an engagement costs is published rather than kept behind a call.

• the public guides and explainers

  The same discipline runs through the public guides and explainers, the quickest way to judge the output before hiring anyone to produce more of it.