Security & access
Whether one customer can see another customer's data, and whether your API keys ended up in code the browser downloads. (Auth, row-level security, secrets, input validation, injection, webhook signatures.)
Built it fast with Cursor, Lovable, Bolt, or v0? Good. That's the right way to start. Before more customers and payments go through it, I'll find the parts that could leak data or lose money. Then I'll fix them and keep what already works.
AI tools are good at getting an app to the point where it demos well. They're much less reliable at the parts nobody sees in a demo: who can read whose data, what happens when a payment webhook fires twice, where the API keys ended up, and whether the database survives its first ten thousand rows.
I use the same AI tools every day, so I know where they cut corners.
Audit. I go through the code, the database rules and the payment setup. You get a written report of every problem I find, ranked by how much damage it could do. Each one comes with a plain estimate of the work to fix it.
Fix. I start with the worst problems and work down the list.
Stay on (optional). I review every change before it goes live, so your team and your AI tools can keep moving without reopening the same holes.
Whether one customer can see another customer's data, and whether your API keys ended up in code the browser downloads. (Auth, row-level security, secrets, input validation, injection, webhook signatures.)
Whether a customer can get charged twice, what happens to your data when a save fails halfway, and whether you could get yesterday's data back. (Schema design, migrations, backups, idempotent payment and webhook handling.)
Whether you hear about errors before your customers do, and whether the app copes when a service it depends on slows down. (Error handling, retries, rate limits, logging, monitoring.)
The slow pages, the slow database queries, and the AI token spend that quietly grows with every new user. (Core Web Vitals, caching, bundle size.)
Whether the next developer, or the next AI session, can change the code without breaking something else. (Types, duplication, dead code, dependency risk.)
How changes reach your live app, whether the flows that make money have tests, and how you'd undo a bad release. (Environments, CI, preview deploys, tests, a rollback plan.)
Rarely. Most of an AI-built codebase is usually fine. The risk sits in a few places: sign-in, who can see which data, payments, and anything that touches your API keys. The audit shows exactly where, so you only fix what matters.
Yes. If it's a React, Next.js, Vue, or Nuxt app with a Node or Supabase backend, I can work with it directly. If a tool locks the code in, part of the audit is getting it into a repository you own.
Yes. If rebuilding costs less than fixing, I'll tell you, with the reasons.
Yes, and that's often the best setup. Your team keeps building while I review, fix the hard parts, and leave behind the tests and guardrails that keep the app healthy.
Bring the repo, or just a description of how it was built. You'll leave the call knowing what's risky and what it takes to fix. I reply within one business day, usually sooner.
