A green build and a 200 response are not proof that the system works. An incident caught before it hits production is worth ten incidents prevented by luck. Pro eMarketing operates a Planner/Generator/Evaluator harness across every venture—not for elegance, but for the incidents it catches, the decisions that cascade, and the certainty it compounds. Every venture on this site was shipped through it.
The Incident
CLT Intel Hub's origin story. A Stripe webhook fires—checkout completed. The app code runs: route handler queries Supabase, updates the subscriber row, returns 200 OK. Stripe marks the webhook delivered.
Except the Supabase write errored mid-flight. The subscription never recorded. The payment was captured. The subscription didn't exist. A customer paid for something they didn't have.
An evaluator agent driving the live app caught it before the gate closed. One finding, one migration. Now every state-changing operation fails closed: 5xx on error, never 200.
Webhook fires
Stripe notifies us: checkout.session.completed
App code runs
Route handler queries Supabase, updates subscriber row
Returns 200 OK
Response sent to Stripe, webhook marked delivered
Silent fail
Supabase write errored but app returned 200; subscription never recorded
"A green build and a 200 response are not proof. An incident caught before production is worth ten prevented by luck."
The System
The Planner/Generator/Evaluator harness is three roles in a loop.
Planner decomposes a venture into phases, gates, and verification criteria. It's strategic: what are we building, why, and how will we know it's safe to ship?
Generator is ~94 named subagents orchestrated in parallel—one per task, each with a clear scope and a decision-making threshold. Planner provides the spec; Generator builds to spec and returns artifacts (code, tests, docs, schema).
Evaluator drives the running application and files findings before a phase closes. It doesn't read code—it exercises the product, tries to break it, and catalogs what breaks. When Evaluator finds something, Planner incorporates it into the standing rules; Generator implements the fix; Evaluator re-runs the gate.
Cost: time and tokens. You're running 90+ agents per venture and driving the product with evaluator loops that can run for hours. It's expensive and it's slow. It's worth it for ventures where a bug isn't an inconvenience—it's a breach of trust.
Why It's a Moat
One incident becomes a standing rule. One standing rule propagates across every venture. The moat is compound.
Webhook returned 200 while swallowing DB error
All state-changing operations must fail closed (5xx on error, not 200)
Stripe webhook, Supabase RLS policies, cron auth, payment handlers
RLS missing on tenant tables, silent deny-all masking a gap
RLS + column-level grants; every table must enforce tenancy at the database layer
All new tables, migrations reviewed for policy gaps, column grants on billing fields
Client sent an untrusted subscriber_id to a SECURITY DEFINER function
Never trust a caller-supplied ID; always derive identity server-side from auth context
API route parameter validation, RPC guards, session-based lookups across all APIs
We don't run five separate ventures—we run one system that learns from each. A security hole closed in one cascades as a policy to all five. A catch in VaultXL is a pattern across CLT Code, CLT Intel Hub, Potty Coach, and SneakerBinge.
The harness is the moat. Not because it's novel—it's pattern-matching + rig + discipline. But because few teams operate this way once. Running it across five concurrent ventures means the learning rate is high and the rule set is battle-tested.
The Evidence
One hero finding per venture. Each deep-links into the case study—the finding lives there; the essay just points at it.
RLS lockdown: silent deny-all masking a design gap
Two tables had RLS enabled with zero policies. An audit uncovered it; column-level grants closed the self-service plan escalation hole.
100x fee double-conversion caught by phase-gated audit
$1,000 stored as $100,000 — a green build shipped past the catch. Evaluator-driven audit found it before customer impact.
Zero-shame regression test across every situation/day combo
A test that scans the coaching engine for banned shame language. Currently stashed, not yet merged — but the class of catch is: tone as an enforced constraint.
83 reversal snapshots: reversibility as a standing control
Snapshot before every bulk change to live client stores. Any operation is precisely reversible — the audit trail that caught every mistake before it stuck.
Redirect-map-before-code: session-weighted 301 strategy
The migration plan itself is the product. Top legacy URL carries ~25K sessions — the map ensures no traffic is dropped, no SEO lost.
Moderation before visibility: safety-first design for grief
Before a grief story ships, an Edge Function runs Claude Haiku over it, flagging shame language or toxic patterns. Moderators review flagged content. Only then does it go live—the opposite of social platforms.
Atomic operations and dry-run discipline for Shopify automation
Every bulk operation runs twice: first on a read-only copy, then for real. Humans review dry-run output before live execution. 145+ automations, zero irreversible mistakes.
Multi-vertical schema with vertical-specific AI and live pricing
Claude Vision identifies items across seven collector categories—watches, sneakers, vinyl, cards, coins, jewelry, art. Live pricing synthesizes eBay, auction results, dealer networks into one valuation.
The Point
For an investor: this harness is what makes five parallel ventures credible from a lean studio. Security incidents don't sink one venture and threaten the portfolio—they become rules that harden all five.
For an employer: it shows the discipline required when the builder is also the operator. The system catches the mistake before a customer does.
For a client: it's why we're comfortable running 145 automation scripts on your live store, why every change snapshots first, and why reversibility is a standing control. We certify the work through the harness before we hand it to you.
When is it overkill? It's not for one-shot projects. It's not for prototypes or domains where "it kind of works" is good enough. It's for the ventures where broken is expensive, where users trust you with money or safety, or where a revert isn't an option. That's why we use it here.