The app works on your screen. Three weeks later a customer emails that it has been down since Tuesday, and the only reason you know is that they bothered. This is the gap, and it is closable without hiring an engineer.
Thousands of applications built with AI coding tools — Lovable, Bolt, Replit, Cursor, v0 and similar — are now serving real users, built by founders, agencies and operations people who are not full-time engineers. The incident record from 2025–26 is consistent: a security scan of about 5,600 publicly deployed AI-built apps found over 2,000 vulnerabilities, more than 400 exposed secrets and 175 personal-data leaks; the named incidents are inverted access rules on a hosted database, API keys shipped to the browser, an AI agent deleting a production database during a code freeze. Underneath the headlines is a quieter pattern: these apps have no one watching them. No uptime check, no error capture, no certificate reminder, no alert — so the first signal is a user. This guide is the production checklist and the monitoring a non-engineer can set up in an afternoon, with the startup monitoring guide as the next step. Facts checked 14 October 2026.
| Exposed secrets | API keys for payments, email or an LLM provider placed in frontend code or a public repo. Consequence: a bill, a data leak, or both. Found in 400+ of 5,600 scanned apps. |
|---|---|
| Missing row-level security | A hosted Postgres (Supabase and similar) with tables readable by any signed-in user, or any user at all. Consequence: every customer can read every customer. The most-cited Lovable-era flaw. |
| Client-side auth | The UI hides the admin page; the API behind it does not check. Consequence: anyone with the URL is admin. |
| Agent with production access | An AI agent given the production database connection runs a destructive command. Consequence: data gone; backups often not configured. |
| Dependency failure | The LLM API, the email provider, the payment processor or the auth service errors or changes. Consequence: a core flow silently fails while the home page loads fine. See third-party outages and LLM API dependencies. |
| Operational lapses | Hosting suspended for a card decline, domain or certificate expiry, a free-tier database paused for inactivity. Consequence: down for days, discovered by a user. |
| Prompt-driven regression | "Make the button blue" rewrites the form handler. Consequence: sign-up broken since the last deploy. See deploy correlation. |
The security checklist covers the vendor-facing questions; these five are the ones you ask your own app.
Something will still get through. When it does: note when the user reported it, when it actually started (your checks will tell you), and the gap between them — that is your time to detect. Add the check that would have caught it. Write five lines: what broke, when, how you found out, what fixed it, what changed. Do this each time and within three months the app is better monitored than most funded startups'.
If the app is for a client — many agencies now ship AI-built apps — the same setup per client, with a monthly report, is the agency monitoring pattern.
| Scanned AI-built apps (2026) | ~5,600 apps: 2,000+ vulnerabilities, 400+ exposed secrets, 175 personal-data leaks |
|---|---|
| Top three security failures | Secrets in the frontend; missing or wrong row-level security; UI-only authentication |
| Top operational failures | Hosting or free-tier suspension; dependency outage; certificate or domain expiry; prompt-driven regression |
| Before production | Search bundle for secrets; test DB as a stranger; hit protected routes logged out; separate prod; restore a backup |
| Minimum monitoring | External checks on app and dependencies; browser error capture; daily SSL check; deploy timeline; one confirmed alert |
| First signal today | Usually a user; the goal is a check that fires first |
They can be, after the same checks any app needs and that these tools often skip: no secrets in the frontend, row-level security on every table, authentication enforced at the server, separate production credentials, and tested backups. A 2026 scan of about 5,600 publicly deployed AI-built apps found over 2,000 vulnerabilities and more than 400 exposed secrets, so assume the checks are needed until you have done them.
Set up an external availability check that requests your app and its key endpoints every few minutes from outside and alerts one person when a failure is confirmed. Add browser error capture with a script tag so broken flows that do not take the site down are also visible. Both can be configured without writing code.
Row-level security is a database feature that restricts which rows each user can read or write, enforced by the database itself. Hosted databases used by AI coding tools often start with it off or with permissive rules, which means any signed-in user — or anyone with the public key — can read every customer's data. Enable it and test as two different users.
Code generated from a prompt can rewrite more than the thing you asked for. Without tests, the regression reaches users. Put deploys on a timeline from your hosting provider's webhook and run external checks on your core flows after each one, so a breakage is tied to the deploy that caused it.
No. Keep development and production separate — different database, different keys — and give agents only the development environment. The best-documented AI-agent incident of 2025 was a production database deleted during a code freeze because the agent had access to it.
External checks on the app and each third-party API it depends on every few minutes, browser error capture via one script tag, a daily certificate and domain expiry check, deploy events on a timeline, and a single confirmed alert to a named person with quiet hours. That set is enough to make a check, rather than a user, the first signal.
Merik's Digital Operations is the afternoon setup in one place. Register the app and each API it depends on as assets (per client, if you build for clients) and Merik checks them from the outside every few minutes — availability, response time and HTTP status — learning a 14-day baseline per monitor so a slowdown raises an early warning with a risk score, a confidence score and the evidence, at most once per asset. Add the browser SDK with one script tag (no cookies, query strings stripped, server-side redaction) and JavaScript errors, unhandled rejections and failed requests arrive grouped by fingerprint per hour. GitHub and Vercel webhooks put deploys on the incident timeline; vendor status feeds for Stripe, Supabase, GitHub, Vercel, Cloudflare, Twilio and OpenAI explain and suppress incidents caused upstream. Confirmed failures open an incident assigned to the asset's owner and alert once, by email or Slack, with quiet hours.
Merik does not scan your code for secrets or audit your database policies; the five pre-production checks are yours. It is also the company workspace — employees, attendance, tasks, clients — so the app's monitoring sits beside the business that runs it. See Digital Operations.
Free, set up for you, every module included — see what the free workspace includes
The monitoring that pays for itself this week, and the monitoring that can wait a year.
The server said 200. The page broke anyway. Seeing the failures uptime checks can't.
Latency drift, 429s and 529s, deprecations, quality drift — checks, alerts and graceful degradation.
Request your free company workspace and bring employees, attendance, leave, payroll and tasks together.