Porting a 46,000-Line SEO Engine Into a Multi-Tenant Platform in Five Days

What We Ported and Why It Was Dangerous

The engine in question is the ancestor of what this research index calls the SEO Command Center: an autonomous system that audits client websites, plans and writes content, applies fixes, and reports on the results. We built the first version inside the studio's own single-tenant codebase, where "the tenant" was always us. By July 2026 it had grown to a 45,886-line Supabase edge function exposing roughly one hundred actions, driven by an operator SPA of roughly 32,000 lines.^[1] The decision was to move all of it into Zyan, our multi-tenant software arm, so that the same machinery could serve any tenant on the platform.

A single-tenant port is dangerous in a specific, enumerable way: every query, log line, budget check, and background job in the source code silently assumes there is exactly one customer. In a multi-tenant destination, each of those assumptions is a candidate cross-tenant leak. The failure mode is not "the feature breaks"; it is "the feature works perfectly and shows tenant A's data to tenant B."

Census Before Code

On July 16, 2026, before any feature code moved, we ran a census: a 28-agent workflow over the legacy engine that produced the port plan as its output.^[1] The census inventoried the roughly one hundred actions and what each one touched, confirmed that the database substrate had already been ported ahead of the code (48 of 48 tables present in the multi-tenant schema), and emitted the build order itself: a fourteen-PR chain of nine backend stages followed by five stacked UI merges, with a security-hardening PR ahead of all of them.

The same day, the owner ratified the credit-metering model that every money seam in the chain would implement: the two metered providers (Anthropic and DataForSEO) are operator-exempt fail-closed. Outside tenants hard-block at zero credits; the agency's own tenant is metered but never blocked. That one decision, made before the first money-path PR existed, shaped everything that followed: reserve before egress, settle on every exit path, and a conversion rate captured at reservation time so a mid-run retune can never reprice work already in flight.

Hardening the Substrate First

The port's first commits were not features. On July 13 and 14, 2026, we repaired the tenancy substrate the engine would land on: a sweep of the tenancy columns across the content, social, and ads table families, and a restoration of owner gates on 83 row-level-security policies across 73 tables.^[3] Then on July 16, the first PR of the port itself was a hardening pass over that latent substrate: it closed four cross-tenant and privilege-escalation defects in row-level security and storage policy.

The ordering is deliberate. A latent defect in an unreferenced table appears harmless until the first feature PR makes it reachable, and by that point the review conversation is about the feature, not the substrate. Closing the four defects first let every later review panel spend its attention on the new attack surface its PR introduced, not on inherited debt.

The Fourteen-PR Chain

The first seven backend stages landed in roughly 48 hours across July 16 and 17, 2026, in dependency order: money first, then evidence, then orchestration, then anything that could write to the outside world. Reporting and cron activation completed the backend on July 18, the same day the five UI PRs stacked on top merged in sequence. In census order:^[1]

• Credits substrate. Atomic consume, reserve, and settle operations as database procedures, per-tenant advisory locks, the conversion rate captured on the reservation itself, and a double-settle guard.
• Audit collectors and a deterministic recommendations engine. The evidence plane: site crawls and provider checks feeding a rules engine whose output is reproducible from its inputs.
• The paid research worker. The legacy engine gated its paid provider calls behind a monthly budget check that failed open. We deleted that gate rather than porting it and replaced it with reserve-before-egress (no provider call without a committed reservation), together with an under-charge floor on settlement.
• The core router. A twenty-eight-action subset of the legacy dispatch surface, with the shared credits adapter replacing the source engine’s fail-open budget gate at every metered call site.
• Setup orchestrator and content radar. Project onboarding plus the feed-watching lane that surfaces content opportunities.
• The autoblog composer. The in-edge Anthropic-driven writing engine, comprising roughly 13,000 lines across eight modules.
• Publishing, shipped dormant. The lane that commits content to client sites landed behind a fail-closed master arm with a dormancy ledger; the code merged, but nothing could publish (discussed below).
• Reporting. Client-facing report generation and secure delivery, built around an XSS census of every sink that renders imported HTML.
• Cron activation. The final backend PR armed the schedule and carried the reaper that drains orphaned money reservations.

The credits substrate came first, so every later stage adopted reserve-and-settle as the path of least resistance rather than as a retrofit. The deletion in the paid research worker was likewise deliberate policy: when a ported component's safety mechanism has the wrong failure polarity, porting it faithfully is a bug. A budget gate that fails open is not a budget gate.

What the Review Panels Caught

Every substantive PR in the chain went through an adversarial review panel before merge: multiple reviewing agents, each assigned a distinct lens (tenancy, money, injection surface, test rigor), together with dedicated refuter agents attacking each finding before we accepted it. On the audit-collectors PR, the panel ran eleven lenses with two refuters per finding.^[2] Refuters eliminated the plausible-but-wrong findings early, so what survived to the fix queue had already withstood a counter-argument. Five catches justify the machinery on their own.

• SSRF, first instance (audit collectors). The collectors fetch URLs in order to audit them, and those URLs are client-controlled. Unfiltered, that is a server-side request forgery hole: a crafted URL could point the platform’s own egress at cloud-metadata endpoints or loopback services. The fix was a dedicated URL classifier with a DNS re-check and a guarded fetch that re-validates every redirect hop.
• SSRF, second instance (autoblog composer). The same class resurfaced four PRs later in a different guise: tenant-editable feed URLs, fetched server-side by the content radar. The shape was identical but the entry point differed, which is precisely why the injection lens repeated on every panel rather than running once.
• A cross-tenant linked-record traversal (core router). One action followed a linked-record reference on a privileged service-role database client, a client that row-level security does not constrain. A tenant who could influence that reference could walk it into another tenant’s data. The catch produced a standing rule: every foreign-key hop made on a privileged client needs its own tenant pin, because the hop before it proves nothing about the row it lands on.
• An aggregate log row leaking tenant names (setup orchestrator). A faithfully ported code path wrote one aggregate activity-log row summarizing work across projects. That row is harmless in a single-tenant system, but in the port it carried other tenants’ project names into a log a tenant could read.
• A reaper that would starve forever (cron activation). The reservation reaper’s candidate query scanned the oldest fifty reservations. Once the oldest fifty were all settled, the scan would re-read those same settled rows every tick, never reaching the unsettled reservations behind them — orphaned money debits parked forever. The fix was an anti-join candidate selector that structurally excludes settled rows.

The smaller catches share the same character. The under-charge floor in the research worker had an edge case where request families that dispatch zero paid calls would trip the floor logic anyway. The composer PR drew four test-rigor findings for vacuous tests, tests that passed regardless of the behavior they claimed to pin; these were rewritten to discriminate before merge. None of these five headline defects reached production; each was fixed inside its own PR, most under formal blocker verdicts.^[2]

Shipping Dormant, Then Activation Day

The publishing lane, the one component that writes to client websites, merged in a state in which it could not act. It shipped behind a fail-closed master arm: unless configuration explicitly arms it, every publishing path refuses. The PR carried a nine-item dormancy ledger enumerating the gates that had to hold for the lane to stay inert; the record documents the ledger as the merge artifact, and we describe it at that level. The riskiest code in the port could thus be reviewed, merged, and deployed on the same timeline as everything else, while the decision to let it act remained a separate, explicit, owner-level step taken later.

Reporting followed on July 18, 2026, and its review centered on an XSS census: the report pipeline stores imported HTML from client sites verbatim, so every sink that renders it was enumerated and sanitized, and URL sinks were fenced separately from markup sinks. The five UI PRs then merged in order: the shell, two feature slices, the credit UI, and finally the 11,637-line command-center page. The last backend PR armed the schedule.

Arming grew the cron schedule from 7 to 12 scheduled rows, and we did not consider the port complete until the first scheduled tick ran and was read back: every step green in the per-step ledger, verified live rather than inferred from the merge.^[4] That first-tick proof has since become standing practice, because code presence is not deployment and deployment is not execution. The scheduling plane has since been consolidated and extended; as of August 14, 2026, its step-liveness registry tracks 33 named steps plus 3 sentinel expectations,^[5] but the arming pattern is unchanged: a schedule change is not shipped until its first tick is observed.

The Port Doctrines

Four rules emerged from this week, and the platform work documented elsewhere in this index has repeatedly re-confirmed rather than revised them.

• Census before code. Measure every action, every table, and every money path in the system you are about to move, and let the plan be the census’s output.
• Hardening before features. Close the substrate’s latent defects before the first feature makes them reachable. Four cross-tenant defects were eliminated on July 16, 2026, at the cheapest point in their lifecycle.
• Dormant-by-config activation. Merge risky capability in a state where it cannot act, behind a fail-closed arm, and make activation a separate explicit decision with its own ledger.
• Review panels as the merge gate. Adversarial, multi-lens, with refuters, on every substantive PR. A gate that runs on every merge finds the second instance of a defect class, not just the first.

Limitations

• The five-day figure covers substrate repair through activation for the feature code. The database schema, comprising 48 tables, had been ported ahead of this window, and the week inherited that head start.
• We cannot run the counterfactual: we cannot prove what fraction of these defects later testing would have caught, or how long the rest would have survived in production. We publish the catch list, not a detection-rate claim.
• Panel composition varied by PR. The eleven-lens, two-refuters-per-finding figure is the recorded configuration for the audit-collectors PR; for some PRs the surviving record is summary-level, and we have not stated per-PR lens counts we cannot source.
• Activation-day "all steps green" proves the schedule executed, not that every downstream capability worked end to end; publishing, deliberately, was still dormant that day. End-to-end proof of the publishing lane came later, under its own arming decision.
• The line counts are the census’s measurements as of mid-July 2026. The engine has roughly doubled since; the numbers here describe what was ported, not what runs today.