Oregon Ghost Conference

The site replaced a third-party booking platform with a custom Stripe-direct flow. Forty-eight class pages, a schedule with in-page preview cards, an add-to-cart drawer, Stripe checkout, post-purchase email confirmations, and refund handling. The first wave landed clean. Every test path I ran end-to-end completed successfully. Customers could browse, add, check out, and receive confirmation emails. Refunds processed through Stripe. The instinct at that point is to call it production-ready and ship.

I ran the adversarial pressure-test instead. Same loop I run on customer brands, pointed at my own production code. Three bugs surfaced that would have shipped to a live conference unnoticed. None of them showed up in normal testing because normal testing follows the happy path. Pressure-testing follows the path where one thing is slightly off and something else fails because of it.

Finding 1: capacity drain on refund

The refund function set the registration status to 'refunded' after Stripe confirmed the refund. Tested in isolation, the function returned 200. Tested against the database CHECK constraint on the registrations table, that exact string silently failed validation. The Stripe refund went through. The seat stayed marked held. Forever.

A customer asks for a refund. Money returns to their card. The room they had booked stays unavailable to anyone else. Whatever capacity the conference operator thought was being sold, was not. This bug does not surface in unit tests because unit tests do not run the live constraint. It surfaces only when refund volume meets a constraint the function did not know about. The fix flipped the status string to 'cancelled', which the constraint accepts, and added a 207 Multi-Status response so the function reports DB-drift after a successful Stripe refund instead of swallowing it.

Finding 2: webhook idempotency gap

Stripe retries webhooks aggressively. A 5xx response, a network blip, a slow handler returning past their timeout window: any of those triggers a retry, sometimes two, sometimes a dozen across a few hours. The original implementation processed each retry independently. Every retry triggered a fresh confirmation email. Every retry could re-confirm an already-refunded order, walking the registration back from cancelled to confirmed because the webhook receiver had no concept of "I already handled this event."

A customer who refunded an event would receive a "you're confirmed" email later that day, sometimes after midnight, with no clear cause. Worse, the system would mark them confirmed in the database again. The fix added an ogc_webhook_events table keyed on the Stripe event ID, with a pending-to-completed transition guard so email side-effects fire exactly once per event regardless of how many times Stripe retries. Webhook signature verification and origin allowlisting on the function entry point closed the related authentication holes.

Finding 3: cart broke on soft-nav

The site uses Astro 5 with ViewTransitions enabled, which means navigation between pages is a soft-nav: the DOM updates in place rather than a full reload. Beautiful when it works. The cart's initialization code was written as an immediately-invoked function expression that fires once on hard page load. On soft-nav from /schedule to /cart, the IIFE never re-fired. The cart appeared visually but the JavaScript that read localStorage, rendered items, and bound the checkout button was silent.

Hard reload worked. Soft-nav did not. Half the traffic to /cart would have silently failed depending on entry path. The fix wrapped the IIFE in a named function bound to the astro:page-load event, which fires on both initial load and every view-transition. Same code, lifecycle-aware. Two related issues surfaced in the same pass: a slug mismatch was producing 404s on two of the evening event pages, and the success page was interpolating customer name and event titles as raw HTML, which is an XSS vector waiting for a customer named with quotes in their string.

What the methodology actually does

Pressure-testing is not running more tests. It is running the system with the assumption that the happy path is a lie until proven otherwise. I look for the edges where two systems meet and assume one of them is silently failing in a way the other does not see. Stripe sends a refund webhook. The DB constraint rejects the status string. Stripe is fine. The DB is fine. The user is not fine and neither system knows. That is the kind of gap pressure-testing surfaces.

The same loop runs on customer brands when I do a Pharallax analysis: read the surface, model the failure modes at each handoff, find the gap before it costs revenue. On the Oregon Ghost Conference site, the gap was in my own code. The fix shipped in a single commit on May 6. Refund flow corrected, idempotency added, cart lifecycle-aware, slug overrides patched, XSS escaping in place. The site went into the next phase production-ready, not first-wave-ready.

The point is not that I write bug-free code. The point is that the gap between "tests pass" and "production-ready" is a methodology, not a moment. I run that methodology against my own code before I run it against a customer's, because I want to know what it feels like to find a finding I did not want to find.