A three-day-old SaaS: twelve findings, ten fixed by dinner

We added a site to Moonleap that had existed for three days: a small SaaS for marketplace sellers, Next.js, deployed on Vercel, built with a coding agent over a long weekend. The analysis raised twelve findings. By the end of the afternoon the same agent had closed ten. This note is what a fresh launch typically misses, what the fixes cost, and the two items that stayed open because they need a person.

What did a three-day-old site miss?

None of these are bugs in the product. They are the gap between "the app works" and "the app is findable and defensible", and a coding agent will not close that gap unless something lists it.

What did the agent fix, and how long did it take?

The agent's own report, condensed:

• llms.txt published: product, audience, how to connect, pricing, six pages, and the facts an assistant should get right.
• Security headers on every route: X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, HSTS. A Content-Security-Policy shipped report-only, with a date to enforce it.
• A social card at /opengraph-image (1200×630, brand colours) and the three Open Graph tags plus the Twitter card on the home page.
• A canonical on every page, pointing at its own clean URL.
• A distinct meta description per page instead of one template sentence on six.
• One plain sentence on the home page saying what the product is, and Organization plus SoftwareApplication JSON-LD.
• /admin removed from robots.txt; the route already redirected to login without a session.

Every item was closed with report_finding and a note saying what changed. The Monday check will re-test each one; if a header disappears in a later deploy, the finding reopens with the agent's own note attached.

What did the repo checkup find that the site scan could not?

The site's public surface was clean after the fixes. The checkup the agent ran inside the repository (61 commits, 166 tracked files, nine minutes) found:

1. The Gemini API key in this repo's .env.local is the same key another of our projects uses, and that other project's coding session had printed it into a transcript on 14 August. One key, two repositories, one exposure. The fix is rotation, and then one key per repository; it is still open because rotation is a human decision with a billing account behind it.
2. Supabase Auth's leaked-password protection was off. One toggle; it is on the list.
3. Seven SECURITY DEFINER database functions were executable by the anonymous role, and one of them had no caller check. The agent fixed that during the checkup with a migration, before reporting.

The site scan cannot see any of this. It is why the checkup is the agent's job, and why the first one is the highest-weighted item on a new project's overview.

What should a launch checklist say, then?

The numbers to keep: a fresh site raised twelve findings; ten were mechanical and took one session; the two that remained were the ones only a person can decide. That ratio is what we see on most new sites, and it is the argument for doing this on day one rather than after the first customer asks why the shared link has no preview.

FAQ

Is llms.txt really the highest-severity item on a new site?

For a site whose buyers ask ChatGPT and Perplexity what tool to use, an AI assistant with no guide to the product is the most expensive gap, and the cheapest to close. The severity reflects the cost-to-fix ratio, not danger.

Why not enforce the Content-Security-Policy immediately?

Because an enforcing CSP that misses one font or analytics host breaks the page for every visitor. Report-only for a week, then enforce, is the safe order.

Can the agent rotate the leaked key itself?

It can change the value in the repository and the host once you give it a new key, but creating the key happens in the provider's console under your account. That is the boundary: the agent does the work, you hold the keys.