Prototype to production · Lovable, Bolt, Replit, Cursor, Claude Code
The prototype proved the idea. Now build the product.
You shipped something real with Lovable, Bolt, Replit, Cursor or Claude Code. Most people never get that far. What those tools don't give you automatically is what comes after: who can see what, what happens when something fails, and what a stranger with dev tools open can reach. We find that, tell you plainly, and fix what needs fixing.
What we actually find
Five patterns keep showing up. They come from the tools' defaults, not your mistakes.
-
Secrets in the client bundle
HighA key that should live only on a server ends up in code the browser downloads, where anyone can read it with dev tools.
-
Password checked, session not
HighLogin works. What's often missing is everything after it: validating the session on the server, invalidating it when the password changes, expiring it, and stopping a copied token from being reused.
-
Access decided in client code
MediumCheckout works. But whether a payment actually unlocks access, and whether cancelling takes it away, is sometimes decided entirely in code the user controls.
-
Row-level security off or incomplete
HighThe finding behind CVE‑2025‑48757, which left 170 apps built with one AI builder readable without a login in 2025. The browser can query the database directly with a public key, and if row‑level security isn't scoped correctly, one account can read another's data.
How to check yours → -
Development and production share everything
MediumSame database, same keys, same deploy button. A mistake made while testing is a mistake in production.
What the tools already check
Every AI build tool now runs some checks of its own. Lovable scans for row‑level security and dependency problems before you publish, and Replit runs a security agent before you deploy. They catch what a scanner can see. They don't decide whether a finding is real for your system, judge authorization rules that depend on your business, or take responsibility for the fix. That part is ours.
How an engagement starts
Three steps, each priced before it starts.
We don't publish a price list. Every engagement is scoped to the actual system, and you get the number before any billable work begins.
- 1 · Triage call
- A short call. We look at the app and the repo and tell you roughly what we'd expect to find, and whether a full assessment is worth it. Sometimes the honest answer is that you don't need us yet.
- 2 · Assessment
- A fixed-scope review covering secrets, auth and sessions, authorization and row‑level security, data integrity, billing, and deployment. You get a written report with each finding's severity, root cause and fix, plus a clear keep, change or replace recommendation.
- 3 · Hardening
- We fix what the assessment found, scoped and priced before we start, and reviewed the same way as everything else we ship. See How We Work.
What you get
- Your tool choice, respected.It got you further than most approaches would have. We build on it.
- A keep-list, not a rewrite.We tell you what to keep, what to fix, and why.
- A price before the work.A bounded, priced assessment comes first, never an open hourly meter.
Questions builders ask
Before you send us the repo.
Is this for vibe-coded apps?
Yes. If you built it with Lovable, Bolt, Replit, v0, Cursor, Claude Code or a similar tool, and it now has real users, real data or real money going through it, this is the work we do. The tool is not the problem. What it leaves unchecked is: who can read and change what, what happens when something fails, and what a stranger with developer tools can reach.
What do you check first?
Who can read and change what. On an app backed by Supabase that starts with row-level security: the browser holds a public key by design, and the database policies decide what it can reach. Then secrets in the client bundle, session handling after login, and any access decision made in code the user controls. How to check row-level security yourself.
Will you rewrite it?
Only the parts that cannot be made safe as they are. The assessment says what to keep, what to change and what to replace, and why, for each part. Most of what an AI builder produced is worth keeping.
Do you work with Supabase?
Yes. The production EHR the founding team built for TrueEval Medical Group runs on Supabase, with each organization's data kept apart by policies enforced in Postgres rather than in the app, and tested. The case study.
What does it cost?
We do not publish a price list, because every app is different. Each step is scoped and priced before it starts, and you have the number before any billable work begins.
Send us what you've got.
The repo or stack, what's working, what worries you, and your timeline.
Next sheet · A‑300