B2B Partner Portal

The Problem

A B2B lead-generation business runs on one thing: getting the right leads to the right partners, reliably, and billing for them correctly. The internal tool that controls all of that — which partners receive which leads, in which postcodes, under which filters — had grown organically into a vibe-coded production app. Most of it had been written fast, by AI coding agents, without the safety scaffolding a system of this consequence demands.

The stakes aren't abstract. The pipeline this portal governs carries roughly 35,000 leads a month across 1,000+ partner accounts. A single mis-saved filter doesn't throw an error — it quietly stops a paying partner's leads, and nobody notices until the revenue is already gone. There were no tests on the money path, no guardrail against one UI action silently overwriting unrelated settings, and a growing backlog of feedback reports with no owner.

My Role

I own this system end to end: I scope the work, decide what gets built and in what order, review every change, gate every irreversible action, deploy, and verify against production data.

What makes the role unusual is how the code gets written. Most implementation is done by a fleet of AI coding agents working in parallel. My value isn't hand-typing every line; it's the judgment layer around the agents — deciding what to automate versus what to gate behind a human, catching the production traps an agent won't see, and designing the verification that proves a change is safe before it ships.

That layer needed real discipline. Early on, parallel agents would pick up each other's in-flight commits — one branch meant for a validation panel quietly absorbed unrelated work — making merges unsafe. So I wrote the operating protocol the fleet now runs under: one agent per worktree, a branch-drift stop rule, an adversarial-review loop before anything merges, and a written session-handoff format so concurrent work stays mergeable and auditable.

This is the honest framing: production system ownership of an AI-written codebase, through orchestration and verification — not solo authorship of every line.

Architecture

What Shipped

The work moved through three phases: first make it safe to change, then make the money path correct, then make the release process itself unable to cause harm.

• Retired the no-code layer under the delivery path. Delivery changes were cut from a brittle Zapier round-trip to direct, canonical writes, with a scheduled monitor that verifies each result by readback and routes mismatches into an explicit failure state rather than silently succeeding. Zapier now has no active function, cron, or trigger in this system.
• Made one edit unable to overwrite an unrelated one. Saving, submitting, or withdrawing one section of delivery criteria must not persist or restore any other section. That invariant is enforced by touched-section gating, restore snapshots, section-aware withdrawal, and a dedicated CI check — the guardrail exists because the failure it prevents is invisible when it happens.
• Replaced a lossy sync with a transactional one. The criteria sync deleted rows before bulk-inserting them, leaving a window where a partner's targeting simply didn't exist; its dedupe and delete scopes also disagreed. Every batch was failing. It was replaced with a bounded transactional operation under canonical advisory locking, fail-closed reporting, and a concurrency test harness that forces two sessions to interleave in reverse order against real Postgres. Verified in production by a single exact-scope canary.
• Reconciled billing at catalogue scale. Two separate defects were capping how much of the invoice catalogue could be seen at all. After fixing the pagination boundaries, the fixes were followed through to completion rather than declared done: 7,872 invoices recovered with zero errors, 397 missing partner invoices restored, and a full overdue audit that corrected 63 invoices whose status had gone stale.
• Repaired a silent data-corruption bug across the partner base. A prefix-collision in the criteria mirror had been quietly mis-mapping option states. Diagnosed, fixed at the resolver, then remediated through a fenced, reviewed production repair: 132 mismatched option-states corrected across 126 partner deliveries, zero false positives.
• Closed security surfaces instead of patching around them. A dormant privileged user-impersonation capability was retired across source and production, with CI guards to keep it retired and live probes proving it was gone. During adversarial review of a row-level-security change, an anonymous-callable RPC that could execute arbitrary SQL was discovered and eliminated. A privileged export was found to be querying globally; scoping it correctly reduced one client's query from a 600,000-row scan to its verified 8,281-row boundary.
• Turned release safety into something the process enforces. A recurring database migration-ledger drift was root-caused rather than repeatedly repaired, and closed with a check that binds agent-run migrations to canonical versions and exact statement encodings — then promoted from an advisory signal into a required, non-bypassable merge gate on main. A production history mismatch was repaired inside a freeze-bound atomic transaction preserving all 348 ledger rows with zero catalog drift; a separate replay failure was fixed by reconciling 14 corrupted records across six failure classes, restoring disaster-recovery replay.
• Built the notification layer end to end. Three operational producers with branded templates, exact-recipient expansion, policy-gated activation, and proof at every step — provider delivery, inbox receipt, and reversible cleanup — replacing an untargeted legacy sender with an auditable outbox.

Verified Outcomes

Every figure above is tied to a dated entry in an evidence-bound impact register that records the baseline, the intervention, the verification method, and the confidence — including the caveats. Claims without evidence are recorded as unknown rather than estimated.

Key Engineering Decisions

• Fail closed, always. When a sync encounters a structure it doesn't understand, it refuses and reports rather than guessing. A partial write to a live delivery path is worse than no write.
• Generate the payload at send time, not at request time. Scheduled changes used to replay whatever was captured when the request was made. If anything moved in between, the system would faithfully apply stale intent. Regenerating at send, then validating the result against the original request, catches exactly that.
• Make overrides expensive but possible. Staff can force a change through, but only with a stated reason, bound to a drift fingerprint, written to an append-only audit record — and large postcode-set changes escalate rather than proceeding.
• Verify by readback, not by return code. A successful API response is not evidence that the external system holds what you intended. Every consequential write is followed by reading the state back and comparing it against intent.
• Retire dormant capabilities rather than leaving them dark. Unused privileged surfaces are a liability that grows quietly. Two were removed entirely, with CI guards to prevent reintroduction.
• Let review overrule the plan. A proposed simplification to a set of complex delivery rules was withdrawn after an independent review found a counterexample involving multi-valued fields. The conservative option won. This happens often enough that it's part of the process, not an exception to it.

Tech Stack

What This Transfers To

The domain is lead routing, but almost none of the hard parts are domain-specific.

• Making an AI-written codebase safe to operate — the problem every team adopting coding agents is about to have
• Correctness on a money path — billing reconciliation, payments, entitlements, anywhere a silent wrong value costs real money
• External system integration with unreliable semantics — readback verification, intent validation, fail-closed sync design
• Release engineering under drift — binding migrations to canonical state and enforcing it at the merge boundary
• Security review of a system you inherited — finding what's dormant, privileged, and forgotten, then removing it