Your app passed the demo.
Production is less forgiving.
AI builders are fast, and the code they produce usually works. What it often skips is the unglamorous layer underneath: row-level security that was never switched on, webhook endpoints that accept unsigned events, service-role keys bundled into client JavaScript, auth redirects still pointing at a preview domain. None of that shows up in the builder. All of it shows up later, usually at the worst time. AppCaretaker is a production audit and maintenance service run by a person who ships software for a living. We read the code and the configuration the way an engineer would, because that is the job.
Audits are read-only. We create a test account, walk the flows, and inspect what your app exposes. We change nothing, and the test data is deleted when the report ships.
What we actually check
This is the working checklist, not a marketing summary. Every item is something we have either shipped wrong ourselves or found wrong in the wild, and each finding in your report names the item it came from.
01 Data access and row-level security
- RLS enabled on every Supabase table holding user data, with policies tested using a second account, not just read
- Firebase rules reviewed for the classic allow read: if true left over from development
- API routes checked for missing ownership checks, the IDOR pattern where changing an ID in the URL returns someone else's record
- Storage buckets checked for public listing and guessable object paths
02 Keys and secrets
- Client bundles scanned for secret keys: Stripe sk_live, OpenAI keys, Supabase service-role keys, anything that belongs server-side only
- Publishable versus secret keys distinguished properly, because the anon key in the browser is normal and the service-role key is a breach
- Environment variable hygiene in the host: test and live credentials separated, no keys committed to the repo history
03 Auth flows
- Supabase Site URL and redirect allowlist compared against the live domain, the single most common reason new users land on localhost after confirming their email
- Full walk with a fresh account: sign-up, confirmation, first login, password reset, logout, session behavior on a second device
- Rate limiting and lockout behavior on login and reset endpoints, and whether error messages leak which emails have accounts
04 Payments and webhooks
- Webhook endpoints verified for signature checking, because an endpoint that trusts any POST can be told a payment succeeded when it did not
- Webhook target URLs checked against the live domain, and the event list compared with what the app actually depends on
- Idempotency handling spot-checked, so a retried event does not grant a subscription twice or email a customer three times
- Prices in the checkout flow compared with the prices on your marketing pages
05 Transport and headers
- HTTPS enforced everywhere, certificate validity and days to expiry, HSTS present
- Security headers reviewed: Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, frame protections
- Cookie flags on session cookies: Secure, HttpOnly, SameSite
- CORS configuration checked for wildcard origins on authenticated endpoints
06 Operations and recovery
- Error monitoring: whether a crash in production tells anyone, or just quietly shows users a white screen
- Uptime and certificate-expiry monitoring, and who gets the alert at 2 AM
- Backups: whether they exist, whether they are automatic, and whether a restore has ever been tested
- Dependency health: known-vulnerable packages, pinned versions drifting, platform API versions approaching deprecation
A sample finding
Every report reads like this: the check it came from, what we observed, why it matters in plain terms, how to reproduce it, and what the fix costs. This example is illustrative, drawn from a failure pattern we see constantly in Supabase-backed apps.
Row-level security is disabled on the table that holds customer orders.
What we observed. The app ships its Supabase anon key in the browser bundle, which is expected and safe on its own. With RLS off, though, that key alone is enough. Using only the key and the project's public URL, we listed rows from the orders table without logging in, including names and email addresses from other customers. No credentials were guessed and nothing was modified; the table answers anonymous reads.
Why it matters. Anyone who opens your site can extract the key in under a minute, and with it, your entire customer list. This is the leak that turns into a very bad email to your users.
How to reproduce. Log out, open the browser console on your home page, and run the query included in the full report. If it returns rows, the finding is live.
The fix. Enable RLS, add policies scoped to auth.uid(), and re-test with two accounts. About an hour of work, quoted in your report as part of the fix sprint, and verified afterwards with the same query, which should return nothing.
How fixes ship
If you hire a fix sprint, the work runs the way a careful engineer would run it on their own product, because the person doing it maintains production software of his own.
Audit first, always
No fix work starts without the audit, and no quote exists before the findings do. You see the full report whether or not you hire anything.
Flat quote, in writing
Each finding gets a fixed price or gets flagged as out of scope with a reason. The quote does not grow mid-sprint.
Pull requests, not surprises
Fixes arrive as pull requests against your repo, with the diff readable and a note on what changed and why. Nothing deploys from a sprint without your merge or your written go.
Verified after
Every fixed finding is re-tested with the same reproduction steps from the report, and the sprint closes with a short summary you can keep with the app.
How we handle access, since you should ask
Audits run on your public app and a test account, nothing more. Deeper checks use read-only access you grant, scoped as narrowly as the platform allows, and you revoke it when the report ships; we will remind you to. We do not retain exports of your customer data, findings are reported with the minimum evidence needed to reproduce them, and an NDA is available on request before any access changes hands. If a finding is severe enough that leaving it feels wrong, we say so in the report, plainly, and then we stop selling and let you decide.
Honest pricing
Founding pricing while we take our first customers. No hourly billing, and a written quote before any fix work starts.
Production audit
Free
The full checklist above, run by hand, with the report in two business days. Read-only, and yours to act on with us or without us.
Caretaker plan
$99 / month
Uptime, error, and certificate monitoring with a human reading the alerts, a monthly health report against the same checklist, dependency and security patch updates shipped as pull requests, and small fixes included. Cancel anytime.
Fix sprint
From $249
A flat-price sprint clearing the findings from your audit, delivered as reviewed pull requests and verified against the original reproduction steps.
From the founder
I build with AI tools every day, and I also operate subscription software in production that real customers pay for, with live billing, live webhooks, and the pager-style consequences when something drifts. That combination is the whole reason this service exists. Building with AI is not the problem. The problem is that the tools optimize for the demo, and production punishes exactly the things a demo never exercises: the second user's data, the retried webhook, the key that was only supposed to be temporary.
You could absolutely prompt your way through every fix on our checklist, given enough hours and enough scar tissue to know what to ask for. Most founders would rather spend those hours on their customers. That is the trade we sell, and if your audit comes back clean, we will tell you that and charge you nothing.
Mark Friske, founder
Fair questions
Is this just AI checking AI?
Fair question, and the honest answer is that scanners help with the mechanical parts, the same way they would help you. The audit itself is a person working a checklist built from real failure modes, reproducing each finding by hand before it goes in the report, and standing behind the fix. If a finding cannot be reproduced, it does not ship in the report as a finding.
Do you need my code or passwords?
Not for the audit. The free checks run on your public app and a test account. Repo or dashboard access only enters the picture for specific deeper checks, always read-only where the platform supports it, always granted by you in writing, and revoked when the work ends.
What if my app needs a rebuild?
Then the report says so, with the reasoning, and we do not sell you a sprint on top of a foundation we just told you is unsound. It happens less often than founders fear. Most of what we find is configuration and a handful of code paths, not architecture.
Which stacks do you cover?
Lovable, Bolt, Replit, v0, and Base44 projects, most often on Supabase or Firebase with Stripe billing and Vercel or Netlify hosting. If your stack is outside that, ask anyway; the checklist travels well, and we will tell you honestly if we are not the right hands for it.
How fast is the report?
Two business days from confirmation for the audit. Fix sprint timelines come with the quote, and most audits produce sprints measured in days, not weeks.
Request your free audit
Tell us where your app lives. We reply within one business day to confirm, and the report lands within two business days of that.