Supabase or a custom backend: when does your app need its own API?
A managed backend such as Supabase is enough while users mostly read and write their own records. Your app needs server code once it has rules users must not skip, secrets for outside services, several clients or events arriving from outside. In most cases the answer is not a custom backend but a thin server layer on top of the managed one.
By cklicky.com · Published · Updated
The short answer
Stay on Supabase alone while your users mostly create and read their own records. Add server code when you have rules a user must not be able to skip, secrets that cannot live in a browser, or several apps that must follow the same rules. A fully custom backend is rarely the first step; a thin layer of server code on top of the managed database usually is.
Supabase is the example throughout because it is so common in AI-built apps, but the reasoning applies to any managed backend.
What a managed backend gives you
A managed backend provides a database, login and file storage that your frontend talks to directly. There is no server of your own to write or run, which is why AI builders favour it.
The security model follows from that design. Because the browser talks to the database, the database itself must decide what each user may see. In Supabase that is the job of Row Level Security, and the documentation is direct about it: enable RLS on every table in an exposed schema. The browser uses a publishable key, which is safe to expose only because RLS limits what it can reach. The secret key bypasses every Row Level Security policy and must never be put in a browser.
Keep that picture in mind: the frontend is trusted with nothing, and the rules live in the database. Every signal below is a case where that picture starts to strain.
Five signals that you need server code
| Signal | Example | Why the managed backend alone is not enough |
|---|---|---|
| Rules a user must not skip | A discount that applies once per customer | Logic in the browser can be changed by the person using it |
| Secrets for outside services | Payment or AI provider keys | A key in the browser belongs to everyone who visits |
| Several clients | A web app, a mobile app and a partner integration | The same rule written three times will drift apart |
| Events from outside | Payment webhooks, scheduled jobs, sync with a CRM | Something has to be listening when no user is online |
| Access that depends on several things at once | Organisation, role and the state of a record together | Possible in database policies, but hard to read and to test |
One signal is usually enough to justify some server code. It is not enough to justify leaving the managed backend.
The middle path: keep the database, add a thin server layer
You do not have to choose between "everything in the browser" and "build it all yourself". The path we recommend most often keeps the managed database and login, and adds a small amount of server code for the rules and the secrets.
Supabase supports this directly with Edge Functions: server-side functions that its documentation describes as suited to listening to webhooks and integrating with third parties, with credentials kept in project secrets. A payment webhook is the classic first use. Stripe signs every webhook event so the receiver can confirm where it came from, and that check has to run on a server.
- Simple reads and writes of a user's own data stay as they are, protected by Row Level Security.
- Anything involving money, quotas or approvals goes through a server function that enforces the rule.
- Every call to a paid outside service goes through the server, with a usage limit.
When a fully custom backend is worth it
Moving to your own API and your own server is a larger step. It pays off when most of your product's value is in its rules, not in its screens:
- Server functions have multiplied until they are a backend in all but name.
- Partners or customers need a documented, versioned API of your own.
- You need background processing that runs for minutes, not seconds.
- Rules about where data is stored or how it is audited require full control.
What that involves is described under our backend development services.
Can you move later? Yes, if you prepare
Supabase is built on PostgreSQL, a standard database, so your tables and data can move to any PostgreSQL host. What does not move by itself is logic scattered through the frontend. Three habits keep the door open:
- Keep business rules out of the browser from the start, even while everything else is simple.
- Store every database change as a migration in your repository.
- Call the backend from one place in your code, not from every screen, so that place can be redirected later.
Three mistakes to avoid on a managed backend
- Tables without Row Level Security, or with a policy that allows everything.
- The secret key in frontend code, added to make a blocked request work. It works because it switches the protection off.
- Trusting the browser with prices, roles or limits. Anything the browser sends can be edited before it is sent.
You can test for all three with our prototype to production checklist. These three account for much of what we repair when we fix a vibe coded app.
A quick way to decide
- List what your product must never allow: paying less than the price, seeing another customer's data, exceeding a quota.
- For each item, ask where the rule is enforced today. If the answer is "in the frontend", that rule needs to move.
- If the rule is about one user's own rows, a database policy is enough.
- If it involves money, outside services or several records, put it in a server function.
- If you now have more than a handful of such functions, plan a proper API.
If the product around this backend is a browser app, our page on AI web app development covers the other half. And if you would like us to look at your case, describe it through the contact form.
Sources
Every external claim in this article links to its source. Checked in November 2026.