Your AI-built app has customers now.
We keep it running.

Supabase's Table Editor switches row level security on when it creates a table. A table created with SQL or a migration, which is how generated code often creates tables, starts with it off. With the public key that ships in every Supabase front end, a table without it can be read and changed by anyone who has the project URL. Row level security mistakes in AI-built apps.

Front-end frameworks inline public environment variables into the bundle at build time. That is fine for the Supabase publishable key, which is designed to be public. It is not fine for the secret (service role) key, which skips every row level security policy, or for a payment or AI provider key that someone else can now spend.

A successful deploy says nothing about whether sign-ups have worked since midnight, whether a background job is still running, or whether the database is running out of connections. Without monitoring and someone on call, an outage lasts until a user notices and decides to write in.

Deployment rollback restores code, not data. A migration that dropped a column, or a release that wrote bad records, needs a database restore. What that restore looks like depends on your Supabase plan, and database backups do not include files held in Supabase Storage. Supabase backups and recovery.

Every account was set up by the person building the app, on their own login, because that was the quickest way to ship. It works until that person is on a plane, ill, or has moved on. Supabase's own production checklist recommends more than one owner on the organisation for exactly this reason.

Supabase's built-in email service is not meant for production and only delivers to your own team's addresses until custom SMTP is set up. Free-plan projects can be paused after a quiet week. These are reasonable defaults for trying something out, and they turn into incidents once customers arrive.

We set up Datadog, which integrates with Vercel, alongside Sentry for application errors, with checks on the endpoints your customers actually use. Alerts are tuned so that each one means something and reaches someone who can act on it. You keep full access to everything we see. Critical Cloud is the world's first Powered by Datadog accredited MSP.

Detection, triage, containment, rollback or fix, and recovery, inside the coverage window you choose. You are kept informed throughout and material changes need your approval. Every SEV-1 incident ends with a blameless root cause analysis, so the same thing is less likely to page anyone twice.

Row level security policies, keys and secrets, storage bucket permissions, authentication settings, webhook verification and who holds admin access. We fix what sits in the platform and explain plainly what needs a change in your code. Our own security posture is certified to ISO 27001 and Cyber Essentials Plus, and it applies to every environment we operate. The security checklist we work from.

We check what your plan already provides, add a copy outside the platform where it is needed, cover Supabase Storage separately, and test a restore into a separate project. The recovery steps are written down, so a restore at 3am follows a runbook rather than a search engine.

The security findings, the noisy alerts, the slow query, the second owner on every account. Improvement engineering works through that backlog every month across reliability, security, cost and governance, so the app becomes safer to run over time rather than just being watched.

Yes. How the code was written matters less than how it runs. We support apps built with Lovable, Replit, Claude Code, Codex, Cursor and similar tools, hosted on platforms such as Vercel and Netlify and using services such as Supabase, Sentry and WorkOS. We start by looking at the production setup as it is today.

No. We operate the app where it already runs. Moving platforms is not a condition of working with us. If we think a change would genuinely help, we will explain why, and the decision stays with you.

If your plan covers that hour, the alert goes to our on-call engineer, not to you. They triage it, contain it, roll back or fix it, and keep you updated until service is restored. Response times are contractual commitments. Recovery times are targets, because recovery depends on the nature of the incident, not just our speed. Every SEV-1 incident gets a blameless root cause analysis afterwards.

Yes, as part of taking on operations. We review the settings that most often expose data in production: database access rules such as Supabase row level security, where keys and secrets live, storage bucket permissions, authentication settings and who holds admin access. You get the findings in priority order, and we fix the ones that sit in the platform. We are not a penetration testing firm or a security operations centre.

No. We operate production and fix what breaks it: configuration, access, database policies, rollbacks and the specific change needed to restore service. Product development stays with you. When a fix belongs in your application code, we explain it plainly and agree who makes the change.

Yes. We check what your Supabase plan already provides, add a copy outside the platform where it is needed, cover file storage, which database backups do not include, and test that a restore works before you need one.