Found 3 critical vulnerabilities two days before launch

The client had built a direct-to-consumer storefront almost entirely with AI coding assistants — a common and reasonable way to move fast as a small team, but one that leaves nobody who has read every line the tools generated. Launch was two days away, with a paid ad campaign already scheduled to start the moment the site went live.

The constraint was time, not scope: there was no room for a multi-week audit, only enough for a fast, focused pass before real customer data and real ad spend started flowing through the system.

Nobody on the team had reviewed the codebase end to end for the basics a security review checks first — how the database is locked down, where secrets live, and whether every route that should require login actually does.

We ran our standard pre-production checklist rather than an open-ended code review: secrets and key handling, database access rules, authentication coverage on every route, data exposure, general production readiness, and — since the product included an AI chat feature — AI-specific risks like prompt injection and data leakage through the assistant. It's a scoped, repeatable process rather than an open-ended audit, which is what makes a two-day turnaround possible.

We found three critical issues. Row-level security had never been enabled on the Postgres tables holding customer orders, meaning anyone with the (guessable, publicly visible) API endpoint could read every order in the database. The Stripe secret key had been used directly in a client-side component instead of a server-only route, shipping it in the frontend bundle for anyone who opened dev tools. And an internal reports dashboard, added late for the founder's own use, had no authentication check at all — reachable by anyone who guessed the URL pattern from the public site's routes.

Each finding came with a fix scoped to be shippable inside the two days remaining, not a longer-term remediation plan the founder wouldn't have time to act on. Enabling row-level security policies, moving the Stripe key behind a server-only route, and adding an auth check to the reports dashboard were each small, contained changes — the point of catching issues this basic early is that fixing them is fast once someone has actually looked.

None of these three were exotic. That was the uncomfortable finding to deliver: they were the kind of gaps a single experienced reviewer catches in an afternoon, sitting invisibly in a codebase that otherwise looked and worked fine. Explaining that to a founder two days before launch — that the product worked perfectly and was still not safe to take payments through — was a harder conversation than finding the bugs had been.

We also had to prioritize under time pressure rather than hand over a long list and wish them luck: we triaged the findings into what had to be fixed before launch versus what could reasonably wait a week, so the founder wasn't stuck choosing between delaying the launch entirely and shipping with known critical gaps.

All three issues were fixed and re-verified before the launch date held. The ad campaign ran on schedule with the exposed database, key, and admin route already closed. As of this writing, no incidents have been reported since.

The client now has us review each major release before it ships, on a recurring basis rather than a one-off — cheaper, in their words, than finding out the hard way a second time.