Vibe-coded app takeover
Your vibe-coded app,to standard, with the proof.
Lovable, Bolt, v0, Cursor, Replit: the demo works and real users are arriving. We read the code, bring it to the eight articles of the standard below, and hand it back with what proves it. You can hold us to the list.
Read-only. You keep the repo and the accounts.
Our rules
- read-only
- we assess before we touch
- no fix without your sign-off
The takeover report
- Summary
- Findings by severity
- Evidence
- Fix
- Keep / refactor / rebuild decision
No public sample yet. This slot stays empty until an owner consents to their report being published.
What breaks
What actually breaks
If three of these lines sound familiar, the takeover is for you. If your app has no users yet, it's probably not the right time — see “Who it's for”.
It leaks
- A user wrote to say they could see someone else's data.
- No server-side ownership check: you read another user's object by changing an id.
- Art. 02
- Anyone can read my database straight from their browser.
- Public key + no row-level security (RLS): reads and writes are open to everyone.
- Art. 02
- An API key is visible in the browser inspector.
- A secret is shipped in the bundle instead of staying server-side.
- Art. 06
- A “paid” status can be set from the browser.
- Billing state is written by the client, not the server.
- Art. 01
It breaks
- Payments go through… sometimes twice.
- Webhook with no signature check and no idempotency: a retry creates a duplicate.
- Art. 07
- Login works, then logs users out for no reason.
- Fragile session handling, no attempt rate-limiting.
- Art. 01
- Every new feature breaks two old ones.
- No test locks the expected behaviour; no CI to catch it.
- Art. 03
No one dares touch it
- I no longer dare ask the AI for a change.
- It already reintroduced a bug; nothing guards against regressions.
- Art. 05
- There's only one environment: I test in production.
- No dev/prod separation; a test touches real data.
- Art. 03
- The code imports a package no one recognises.
- A dependency invented by the model, never verified (supply chain).
- Art. 06
- I have a deadline and don't dare look under the hood.
- Client demo, raise or audit: no one knows what the app really holds.
- Art. 05
The takeover
How it works
A line starts from your app as it is, runs through a read-only audit that produces a report ranked by severity, stops at a gate — your sign-off — then bringing it to standard, one reviewed PR per topic, and ends with the handover: tests, CI, documentation and proof, yours.
Your app
A conversation, the repo or app link. Nothing to install, nothing to prepare.
A straight first opinion
Audit
We read the code, the schema and the configuration, read-only; no writes, no secrets copied. Findings are ranked by severity, tied to the standard, with the evidence and the proposed fix.
The takeover report
To standard
Fixes in order of severity, one PR per topic, reviewed. Nothing is merged without your sign-off; you keep control of the repo.
Reviewable PRs
Handover
Tests, CI, documentation, linked proof. You — or your next developer — can carry on without us.
Code you own
Timeline and price are set in writing after the repo is read, before any work. No grid, no surprise invoice.
The standard
Eight articles.Hold us to them.
Eight articles, public. The first four are the ones that fail first in a vibe-coded app. The next four make it maintainable.
0 / 8 articles have a public receipt
The four locks — the same standard we hold ourselves to
The four locks
Authentication and 2FA
not yetEvery route requires a valid session; access control is checked server-side, and 2FA is available for sensitive accounts.
HighHow we verify · Review flow, reset, expiry; role/payment fields server-side
No public receipt yetFull answerData: per-account RLS
not yetEvery exposed table has an access rule that is correct, not merely present; a user reads and writes only their own data.
CriticalHow we verify · Queries with the public key + cross-account isolation test · Read/write another account's object, route by route
No public receipt yetFull answerPipeline: green CI
not yetA pipeline runs types, lint and tests on every change; nothing reaches production without going green.
HighHow we verify · We break a test on purpose: CI must fail · Dev/prod separated, reproducible deploy, rollback
No public receipt yetFull answerSecurity headers
not yetSecurity headers (CSP, HSTS, content-type, frame, referrer) are set and checked on the real deployment.
HighHow we verify · Header scan (CSP, HSTS, content-type, frame, referrer) against the production URL, not the preview
No public receipt yetFull answer
Maintainability
Strict types and tests
not yetStrict TypeScript at the boundaries; risky paths (access, payment) are covered by tests that fail when behaviour breaks.
HighHow we verify · Cover access and money paths first · Server-side validation, output encoding (XSS, injection)
No public receipt yetSecrets and dependencies
not yetNo secret in the bundle, repo or git history; dependencies are audited and every package actually exists.
CriticalHow we verify · Inspect the shipped bundle and git history · Secrets out of the repo, rotatable, dev/prod separated · Review write access granted to AI tools · Lockfile audit, package-name verification
No public receipt yetHandled errors and observability
not yetExpected failures are handled, unexpected ones logged and alerted; there is one place to look when something breaks.
CriticalHow we verify · Replay a webhook: one event, a single effect · We trigger a failure: usable trace and alert
No public receipt yetClean exit from the platform
not yetThe repo is yours, the deployment is documented and reproducible; no hidden dependency on the original platform.
MediumHow we verify · Restore tested at least once, migrations versioned
No public receipt yet
Passing all eight articles does not prove your app is safe; it proves these eight checks pass.
Severity. Critical = exploitable today by a stranger. High = blocks growth or breaks under load. Medium = debt that will cost later.
These eight articles are the list. A takeover aims at all of them, article by article — and this page says which are already proven.
Public documents
- Takeover report · samplenot published
- Demo repositorynot published
- Before / after capturesnot published
published only at the owner's request
The decision
Keep, refactor or rebuild
A gate asks the question: does the data model hold? If it holds, we repair. If it holds but everything is tangled, we refactor. If it contradicts itself, we rebuild. No branch is favoured; the answer comes from reading the code.
Repair
The data model is sound and the screens are worth keeping: we close the holes and add the nets (tests, CI, alerts).
Refactor
Logic and permissions are tangled into the UI: we separate first, then repair. The result holds up.
Rebuild
The data model contradicts itself, or no one can say what the app does: each fix costs more than rebuilding.
The rule: the data model is the threshold. If it holds, we repair around it. If not, we tell you.
If rebuilding is cheaper than repairing, we'll tell you — even if it means a smaller quote for us.
Who it's for
Who it's for, and who it isn't
It's for you if
- your app has real users, or a launch coming up
- it handles personal data or payments
- you want the truth before you spend
- you want to keep ownership of the code
- you accept “rebuild it” as a possible answer
It's not for you if
- you have no users yet (the platform is still enough)
- you want the cheapest quote rather than the straightest opinion
- you need a compliance certification (we don't issue one)
- you want to add features before fixing the holes
Questions
Straight answers
Not by default. The report decides keep, refactor or rebuild, with the reason. The threshold is the data model.
Not to start: read-only access to the repo and the app. If a fix needs it, it's on a branch, with your agreement, and the access is revocable.
You, fully: repo, accounts, database, keys. We work in your accounts or a fork you own.
Yes, if you'd like, before we open anything. Send yours or ask for ours.
Budget and timeline are given in writing after the repo is read, before any work. They depend on what breaks, not on a grid. No price shown here.
Not on principle. We harden it in place or take the code out, after reading. What matters is that the code and accounts are yours.
Keep those scans: Lovable's and Supabase's exist and are useful. Their own documentation says it: they cannot guarantee complete security. A scan checks that a rule exists; we read the code and test that it is correct, by trying to read what we shouldn't. Lovable's security page (opens in a new tab)
Send the repo
Show us the app.We read first. We don't sell.
The demo worked. Let's see where it stands against the eight articles. A link and an address are enough; we read before we propose anything.
What happens next
The draft opens in your mail client; nothing leaves this page.
We reply by email with a straight first opinion.
Read-only access: a read-only GitHub collaborator, or a zip archive. We never ask for a service-role key, production credentials or a .env file.
Rather talk it through before sending anything?
Or write to us directly: hello@aerialabs.com