Audit of an MVP built with AI
Built your MVP with AI? We'll help you check the code, the architecture and whether it is ready for a real launch. You got a working product fast — we'll show you what to keep, what to fix before your first paying users and what to replace so you can keep building with confidence.
- Access & roles
- Secrets
- Tests
What is an audit of AI-written code?
It is a review of an application built with Cursor, Claude Code, Lovable, Bolt, Replit or similar tools, before launch or growth. We look at what is easy to miss when building fast: who can see whose data, where the keys live, whether the API checks who owns a record, whether the main journey has tests, and whether builds and deployments are reproducible. You get a risk map, a keep / fix / replace decision per module and a plan for the next phase.
Who comes to us
A founder who built the MVP themselves
The product was made in Lovable, Bolt or Replit, and the first users are here or about to arrive. You need to know whether it is safe to open sign-ups and take payments.
A developer working with Cursor or Claude Code
Code gets written fast, but nobody reviews it from the outside: there is no senior colleague to check access, the data schema and deployment.
A team without a senior engineer
A few people are building the product and architectural decisions were made along the way. Before growth you need an independent view and a clear order of work.
Before an investor or a new contractor
An investor, a new team or a technical partner asks what state the code is in. You need an evidence-based picture, not a guess.
Questions people bring
Can we launch an MVP if AI wrote almost all of the code?
How code was written says nothing about its quality on its own. AI assistants write routine code confidently, but they can miss what is invisible in the UI: server-side permission checks, table access rules, key storage. The audit answers the question for your specific application.
Can one user see another user's data?
We review the role model, the database access rules (for example, RLS in Supabase and PostgreSQL) and the ownership check in every API route that takes an ID — on a test environment, using test accounts.
There is a key in the frontend code — is that dangerous?
It depends on the key. A public Supabase or Firebase key is meant for the browser — as long as access rules are in place. A secret key for a service, a payment provider or an LLM API in the browser is a real problem. We look at every key we find individually.
The assistant breaks something with every change — should we rewrite everything?
Usually not. Tests for the main journey, clear module boundaries and schema migrations tend to help more. We make the keep / fix / replace call per module, not for the whole product.
What we actually check
items
- Authentication and authorization: roles and permission checks on the server, not just in the UI
- Data access: database rules (RLS and equivalents), object ownership checks in the API
- Secrets: keys in client code, in the repository and its history, environment separation
- APIs: input validation, error handling, extra fields in responses
- Dependencies: known vulnerable, abandoned and suspicious packages
- Database schema: migrations, manual edits, backups
- Architecture: duplicated logic, hidden coupling between modules, outdated APIs in generated code
- Tests: whether the main journey is covered and whether tests catch real breakages
- Build and deployment: reproducibility, environment variables, rollback, basic operational risks
Signs it is time for a check
None of these means the product is bad. Each is a reason to take a closer look before load and payments grow.
No tests
You check every change by hand, and something still breaks somewhere else.
Unclear who can see the data
Table access rules were never set up — or were set up just to make things work.
Keys on the client
API keys live in the frontend or in a .env file that ended up in the repository.
Everything depends on one person
Only the author knows how the product works — plus their chat history with the assistant.
Builds and releases are unpredictable
Deploys succeed on the second try, it works locally but not on the server, and releases break old features.
The schema was edited by hand
Tables were changed in the dashboard, there are no migrations, and recreating the database elsewhere is hard.
Review formats
Three scope reference points. We tailor the exact contents to your product after the brief.
Quick Review
Quickly understand the main risks before showing the product to users or an investor.
- Roles and access in key journeys
- Secrets in code and the repository
- Data access rules (RLS and equivalents)
- The most important fixes, as a short list
Outcome: a short report — the main risks and the review boundaries
Not included: broad code coverage, a detailed review of tests and architecture.
MVP Review
An MVP before opening sign-ups, taking payments or onboarding the first paying customers.
- Everything in Quick Review
- APIs: validation and ownership checks
- Tests for the main journey
- Build, deployment, environment variables
- Database schema and migrations
Outcome: a risk map, keep / fix / replace per module, a roadmap
Not included: pentest, load testing, fixes.
Deep Audit
A product with users and payments, before growth, investment or a handover to another team.
- Everything in MVP Review
- Architecture and module boundaries
- Dependencies and supply chain
- Backups and restore
- Logs, monitoring, operational risks
Outcome: a two-level report — for the owner and for the team — with a roadmap
Not included: pentest, certification, a promise that no vulnerabilities remain.
The cost is set after the brief and once the scope is agreed. The formats are reference points, not fixed plans: we tailor the contents to your product.
What you get
A risk map
Evidence-backed findings: severity and confidence kept separate, and what was not reviewed is stated plainly.
Keep / fix / replace
A decision for every module: what works and should be left alone, where a targeted fix is enough, what is simpler to replace.
A roadmap for the next phase
Targeted fixes in priority order, plus advice on how to keep building with an assistant more safely.
Sample findings
This is how findings look in a report. The product is fictional; these issues are typical of apps built fast, but they show up in hand-written code too.
Summary for the owner
- System: a fictional class-booking service built in Lovable and extended in Cursor — React, Supabase (PostgreSQL, Auth), Edge Functions. Format: MVP Review.
- We do not recommend taking payments yet: the customer table can be read with the public key without signing in (F-01). The fix is targeted.
- Keep the UI and most components. Fix the data access layer. Replace manual schema edits with migrations.
- First steps: F-01, F-02 and F-03 before taking payments; F-04 and F-05 before a second developer joins.
F-01CRITICALThe public database key exposes the customer table: RLS policies are not enabledData access · RLS
- Observed
- The app calls Supabase from the browser with the public (anon) key — exactly as the platform intends. But Row Level Security is disabled on the clients and bookings tables, so a request with that key returns every row.
- Evidence
- Schema export of the fictional project; on a test copy, a request without signing in returned all test customer records.
- Business impact
- Every customer's name and phone number is available to anyone who opens the browser's developer tools. Legal and reputational consequences of a data leak.
- Recommendation
- Enable RLS on every table holding user data, write “users see only their own rows” policies, and verify them with tests under different roles.
- Confidence · reproducibility
- HIGH · CONFIRMED
- Priority · effort
- P0 — before taking payments · S
- Limitations
- Tables in the schema as of the review date were checked; file storage was sampled.
F-02HIGHThe payment provider's secret key ended up in the client bundleSecrets
- Observed
- A variable with the VITE_ prefix holds the payment provider's secret key. The bundler inlines such variables into the JavaScript the browser downloads.
- Evidence
- A search of the built bundle from a test build and the build configuration; the key value is redacted in the report.
- Business impact
- The key allows calls to the payment API on behalf of your account — creating operations and reading transaction data.
- Recommendation
- Rotate the key, move payment API calls to the server (an Edge Function or an API route), and keep only the publishable key on the client.
- Confidence · reproducibility
- HIGH · CONFIRMED
- Priority · effort
- P0 — before taking payments · S–M
- Limitations
- The key was not used to call the provider — that was out of scope; its permissions were assessed from the provider's documentation.
F-03HIGHThe cancel-booking function does not check whose booking it isAPI · ownership check
- Observed
- The cancel-booking Edge Function accepts a booking_id and runs with the service key, which bypasses RLS; it never checks that the booking belongs to the current user.
- Evidence
- supabase/functions/cancel-booking/index.ts, lines 12–30 (fictional); on the test environment, test user A cancelled test user B's booking.
- Business impact
- Any registered user can cancel other people's bookings — lost revenue and lost customer trust.
- Recommendation
- Call the function with the user's token instead of the service key, or explicitly compare the booking owner with the user from the token; add a test for someone else's booking.
- Confidence · reproducibility
- HIGH · CONFIRMED
- Priority · effort
- P0 — before taking payments · S
- Limitations
- Booking and cancellation functions were reviewed; admin functions were sampled.
F-04MEDIUMNo tests for the “book → pay → get confirmation” journeyTests
- Observed
- The repository has a few generated unit tests for formatting helpers; the main user journey is not covered, and CI does not run tests.
- Evidence
- The tests/ folder and CI configuration of the fictional project.
- Business impact
- Any change — by hand or by the assistant — can silently break booking or payment; customers will notice first.
- Recommendation
- Pin down current behaviour with an end-to-end test of the main journey and integration tests for access rules; run them in CI on every pull request.
- Confidence · reproducibility
- HIGH · CONFIRMED
- Priority · effort
- P1 · M
- Limitations
- The quality of existing unit tests was sampled.
F-05MEDIUMThe schema was edited by hand in the dashboard; migrations lag behind the databaseDatabase · migrations
- Observed
- The database has columns and indexes that are missing from the migrations folder; some changes were made manually in the dashboard.
- Evidence
- A comparison of the schema export with the supabase/migrations folder; the team confirmed some of the differences verbally.
- Business impact
- You cannot reliably spin up a copy of the database for tests or a new environment; rolling back schema changes is manual.
- Recommendation
- Capture the current schema as a baseline migration, change the schema only through migrations in the repository from now on, and document the restore procedure.
- Confidence · reproducibility
- MEDIUM · INDICATED
- Priority · effort
- P1 · M
- Limitations
- Restoring from backup was not tested: it was outside the MVP Review format.
Demonstration sample. The product, project, code, paths and data are fictional. Severity reflects consequences weighted by likelihood; confidence reflects how well the fact is proven. S / M / L is a relative effort class, not an estimate in hours.
Self-check, consultation or audit
You do not always need an audit. Sometimes a self-check or one conversation with an engineer is enough.
| Aspect | Self-check | Consultation | Audit |
|---|---|---|---|
| When it fits | You want to know where to start | You have a specific question: stack, access, data schema | You need a picture of product risks before launch or growth |
| Who looks at the code | You do | An InterLAB engineer — from context and safe snippets | An InterLAB engineer — the repository within an agreed scope, read-only access |
| Outcome | A list of what to check first | Options, trade-offs and next steps | An evidence-based risk map, keep / fix / replace, a roadmap |
| Cost | Free | After the brief and an agreed scope | After the brief and an agreed scope |
A self-check does not replace an audit: it tells you where to look, but it cannot see your code.
How to share access safely
We only open the code after an NDA and an agreed scope. Until then, a description is enough.
- 01
Do not send code via the form or WhatsApp
The form and messengers are only for a short description of the task. Do not send source code, passwords, keys or tokens through them.
- 02
NDA and scope first
NDA on your template or InterLAB's. We agree which modules and environments are reviewed and what stays out of scope.
- 03
A separate read-only account
Invite a separate account with read-only access to the repository, temporary where possible. There is no need to share your own login.
- 04
A test environment, not production
We test access rules on a copy of the project with test data. Active testing of the live product happens only with your written consent.
- 05
Secrets stay with you
The audit does not need your keys. If we find a secret in the code, it is redacted in the report, and we recommend rotating it right away.
- 06
Access revocation
Once the report is delivered, you revoke the access you granted, and we confirm it together.
The report delivery channel and how long materials are kept are set in the contract.
Next step
You can start on your own — with the self-check and lessons from the library.
How the audit runs
- 01
A short brief
What the product is, what it is built with, whether there are users, payments and personal data, and what worries you. A description only — no code or keys.
- 02
Format and scope
Quick Review, MVP Review or Deep Audit: we agree the modules, environments and what is out of scope. The cost follows once the scope is agreed.
- 03
NDA and read-only access
NDA on your template or ours, read-only repository access. Real customer data is not needed.
- 04
Review
Manual review of code and configuration, plus access-rule checks with test accounts on a test environment. Every finding comes with evidence.
- 05
Risk map and per-module decisions
Findings with severity and confidence, keep / fix / replace per module, a roadmap for the next phase.
- 06
Then it is your call
Fix things yourself, hand the report to another team, or order stabilization from InterLAB under a separate contract.
Get your project assessed before development starts
Describe the task in the form below — we reply within a business hour and suggest the next step: a call, a review or an estimate.
What people build with
Where the product was built does not matter: we review the resulting code, data schema and configuration. We name the tools so it is clear who comes to us: they speed up development, but building fast has typical blind spots.
- Cursor
- Claude Code
- Lovable
- Bolt
- Replit
- v0
- GitHub Copilot
- Windsurf
A typical AI-built MVP stack
Most often it is React or Next.js on the frontend and a BaaS platform instead of a custom backend. Each platform has its own access rules — and those are what we check first.
Supabase, Firebase, PostgreSQL, Next.js, React, Node.js, Vercel, Netlify
Questions about auditing an AI-built MVP
No. How code was written says nothing about its quality on its own: assistants handle routine tasks well. Risks appear where a decision needs context the assistant did not have — access rights, secrets, the data schema, behaviour on failure. That is what we check.
The cost is set after the brief and once the scope is agreed: it depends on the format, the number of modules, and whether payments, personal data and integrations are involved.
No. A description is enough for an estimate: what the product is built with, which roles exist, whether there are payments and personal data. We open the code only after an NDA and an agreed scope — through read-only access.
No. It is an evidence-based review of code and configuration within an agreed scope — not a penetration test, not a certification and not a promise that no vulnerabilities remain. The report states plainly what was reviewed and what was not.
A general technical audit is for live products of any origin and covers a broad set of domains: architecture, performance, integrations, legacy. The AI-built MVP audit focuses on the risks of building fast: data access, client-side secrets, server-side checks, tests and reproducible deployments.
The recommendations take your workflow into account: tests that catch breakages after changes, repository rules, a review routine for changes. The goal is for you to move just as fast, with less risk.
We can, under a separate contract. But the report is self-contained: your team, a freelancer or another contractor can work from it — you do not have to order fixes from InterLAB.
Deep dives in the blog
Related services
We'll show you what to keep and what to fix
Tell us what the product is built with and what worries you — no code, keys or passwords. We will suggest the right review format.
- The first short conversation is free — we choose the format
- NDA — yours or ours
- Pricing after a brief and an agreed scope