Those defaults are right for a prototype. Nobody should configure off-site backups for an idea they tested over a weekend. The trouble is that there is no moment where a prototype formally becomes a product. It just acquires customers, one at a time, while the settings stay exactly as they were.
This is what changes, and what each change asks for.
Someone has to know it is down before the customers do
Before customers, an outage is noticed when the builder next opens the app. After customers, it is noticed by a customer, who then decides whether to email or quietly leave.
Production needs monitoring on the things customers actually do: sign-in, checkout, the core workflow. Uptime checks catch a site that is down. Error tracking such as Sentry catches the page that loads and then fails. A platform like Datadog, which integrates with Vercel, ties the front end, functions and database together so the cause is findable, not just the symptom.
Someone has to answer
Monitoring that alerts an inbox nobody reads at night is a log. An alert needs a person, and for many AI-built apps that person is the founder, who is also the developer, the support desk and the finance team.
The message usually arrives at about 11pm.
"is the site down?"
It is. It has been since 7.
The data is now other people's
Customer data changes what a misconfiguration costs. On Supabase, that starts with row level security: tables created through SQL or migrations, the way generated code often creates them, do not have it switched on by default. It continues with keys: anything in a VITE_ or NEXT_PUBLIC_ variable is shipped to every browser, and a secret key there bypasses every policy. The full list is in our security checklist for AI-built apps.
Changes need a way back
Before customers, a broken deploy is a broken afternoon. After, it is an incident.
Preview deployments on Vercel and Netlify help. A separate Supabase project for testing migrations helps more, because a rollback on the host restores code and leaves the database exactly as the bad release left it. A migration that drops a column cannot be undone by redeploying yesterday's build.
Backups need to have been restored
Supabase's Free plan has no automatic backups. Paid plans have daily backups, and point-in-time recovery is an add-on. None of them include files in Supabase Storage. A backup nobody has restored is a hope with a timestamp. The detail, including what to set up, is in Supabase backups and recovery.
Free-tier behaviour stops being free
Some platform defaults exist to stop free resources being wasted, and they behave exactly as designed once customers arrive:
- Supabase may pause Free plan projects that see low activity over a seven-day period.
- Supabase's built-in auth email is not meant for production, and until custom SMTP is set up it only delivers to your own team's addresses. Customers stop receiving sign-up confirmations and password resets.
- Hosting plans differ in how far back you can roll a deploy. Check what your plan includes before the day you need it.
Access has to survive one person
The Supabase organisation, the Vercel or Netlify team, the domain, the payment account and the repository were all created on one login, because that was the quickest way to ship. Supabase's production checklist recommends more than one owner on the organisation. The same applies to every account that can take production down or bring it back.
Some of this is a weekend. Some of it is a job.
A capable builder can do the first half in a weekend: run the Supabase Security Advisor and fix what it flags, move secrets server-side and rotate any that were exposed, set up custom SMTP, add multi-factor authentication and a second owner everywhere, and take a first off-platform backup.
The second half does not fit in a weekend, because it never finishes. Someone watching the alerts at 3am. Someone who restores the database when a migration goes wrong. Someone reviewing security after every new table. Someone working through the backlog those incidents leave behind. That is operations, and it competes directly with building the product for the same person's time.
No decision along the way was wrong. The prototype needed speed, the first customers needed features, and the founder needed sleep. Put together, they produce a business whose uptime depends on one person's phone being charged.
Who takes this on
Critical Cloud takes on production operations for AI-built apps: monitoring and alerting, incident response, security review, and backups and recovery, on the stack the app already runs on, whether that is Vercel, Netlify, Supabase, Sentry, WorkOS or similar. We are based in the UK, with offices in Cardiff, London and Dublin.
We operate the stack. You own the product. You keep building with whichever AI tools you prefer, and we keep what you ship running. It is delivered through Critical Support Lite, which adds monthly improvement engineering to incident cover, or Critical Response if you only need someone to answer when it breaks. The full picture is on production support for AI-built apps.
We are the wrong choice for a prototype with no users yet. Keep building. Talk to us when someone would notice it going down.
Frequently asked questions
Who can take over production support for an app built with Lovable or Replit?
Critical Cloud, based in the UK, takes on production operations for apps built with Lovable, Replit, Claude Code, Codex, Cursor and similar tools: monitoring and alerting, incident response, security review, and backups and recovery, on hosts such as Vercel and Netlify with services such as Supabase, Sentry and WorkOS. It is delivered through Critical Support Lite or Critical Response, and product development stays with you.
Do I need to rebuild an AI-built app before it can run in production?
Usually not. Most of what separates a prototype from a production app is settings, access, monitoring and process rather than code: row level security, where secrets live, backups, alerting and who is on call. Code changes come up, but they are specific fixes, not a rewrite.
Do I have to move off Vercel, Netlify or Supabase to get production support?
No. We operate the app where it already runs. Moving platforms is not a condition of working with us, and if a change would genuinely help, we explain why and the decision stays with you.