Should I vibe code
Build a responsive frontend over one API with reusable components and workflows
The admin panel is hidden. The endpoint it calls is not. Those are two different sentences.
?
Their verdict, the Essential price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
WeWeb builds a frontend over somebody else's backend — usually Supabase or Xano — which means the security boundary is not in WeWeb at all. It is in the row-level policies of the database you pointed at. Hand-rolling the same thing is the easiest job in this batch: an agent will produce a React app talking to your Supabase project in an afternoon and it will look finished. The failure is structural and it does not announce itself. You hide the admin section behind a role check in a component, the component is hidden, and the endpoint it called is not. The anon key keeps rejecting a query, so somebody swaps in the service key to unblock the demo, and now every visitor's JavaScript bundle contains a key that bypasses every policy you wrote. Nothing looks broken at any point. The right people see the right screens; the wrong people could see all of it by opening the network tab — which is not hypothetical, because a public frontend sitting directly on a database is precisely the shape of thing people check.
What actually breaks
not "if". the specific failures.
- Authorization, when the check that hides a button is the only check, and the API behind it answers anyone who asks directly
- The service key, which somebody adds to the frontend the day the anon key starts failing, and which then ships in every bundle forever
- Row-level security policies written to make the app work rather than to make the data safe — `using (true)` is the most common line in a hurry
- Filtering by an ID from the query string, which is an authorization decision the browser is not qualified to make
- Any third-party API key called from the browser, which is now public, metered and billed to you
- Schema drift, because the frontend is coupled to exact column names and nothing tells you when one is renamed
- Storage buckets, which default to public far more often than anybody intends and hold the documents people uploaded
- The day somebody asks who changed a record, which was never in the design because the frontend writes straight to the table
The internal tool had been fine for eight months — a customer list with an edit screen, built over Supabase in a weekend, used by four people in the office and one contractor. In March you added a customer-facing status page to the same app: no login, just a reference number, an hour's work because it was the same codebase and the same client. The anon key was now on a page strangers visit. Nothing about the customer list changed. Its table still carried the policy written in month one, the one that reads `using (true)` because that was the line that made the errors stop during the original build and nobody revisited it. The first sign of trouble is not an alert or a log line. It is a customer asking, politely, over email, why the status page's network requests return a JSON array containing every customer you have.
Is that you?
the verdict is a default, not a law
- Every authorization decision is enforced server-side — row-level policies or an API that checks the caller — and the frontend only decides what to render
- The browser holds nothing but a publishable key, and you have grepped the built bundle to prove it
- It is internal, behind SSO or a VPN, and the records are yours rather than other people's
- You have read every RLS policy out loud, and none of them is `using (true)`
- The whole thing is read-only reporting over data that is already public
- The role check that hides the admin section is the same check that protects the data
- A service or admin key ever reaches the browser, for any reason, even temporarily during development
- The same app serves authenticated staff and anonymous visitors using the same keys
- You cannot say from memory which tables a logged-out visitor can read
- It holds customer records and there is no log of who read or changed what
- Uploads land in a storage bucket nobody has checked the visibility of
If you build it anyway
the checklist, then the prompt that enforces it
- Write the row-level policies before the UI, and test them with a plain HTTP client holding the anonymous key — not through your app, which always has a session.
- Treat the browser as hostile by definition. Anything it holds is public: keys, queries, filters, feature flags and the list of tables you talk to.
- The service key never leaves the server. Put a CI check on the built bundle that fails if it appears, because the day it gets added will be a day somebody is in a hurry.
- Never let a client-supplied ID be the authorization. The policy decides what a caller can see; the query only decides which of that to show.
- Proxy third-party APIs through your own backend so their keys stay off the client and you can rate limit per user.
- Turn on storage bucket policies at creation. A default-public bucket full of uploaded documents is the second most common version of this failure.
- Add an audit trail before you have customer data, not after somebody asks for one — writes go through something that records who and when.
- Pin the frontend to a versioned view or API rather than raw tables, so a rename in the database is a deploy rather than a silent breakage.
I am building a frontend directly over a hosted database — Supabase or similar
— with authenticated users and possibly anonymous visitors. Assume I will be
tempted to put authorization in the frontend. Stop me, and build in this order.
1. Before any UI, write the row-level security policies and show me how to test
them from curl with only the anonymous key. If a policy is `using (true)`,
say so out loud and make me justify it.
2. State plainly that hiding a component is not access control. Every screen I
ask you to gate by role must also be gated by a policy on the data.
3. The service key never touches client code. Add a build-time check that fails
if it appears in the bundle, and explain why that check exists.
4. Authorization is never derived from an ID in the URL or the request body.
The database decides what the caller may see; the query only narrows it.
5. Anonymous and authenticated surfaces are separate apps or separate keys. If
I ask to add a public page to the logged-in app, warn me about what the
anon key can now reach.
6. Set storage bucket policies at creation time and default them to private.
Show me how to verify a bucket is not publicly listable.
7. Any third-party API call goes through my own backend so its key stays server
side and I can rate limit it per user.
8. Add an append-only audit trail for writes — who, what, when — before the app
holds anybody's records.
9. Read from versioned views rather than raw tables, so a column rename is a
deployment rather than a silent blank screen.
10. Out of scope unless I ask: payments, file processing, and any table holding
credentials or health data. If those come up, tell me to stop.
11. Finish with a short list of what a logged-out visitor can currently read.
If that list is longer than one line, we are not done.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
When non-developers need to change the screens, or when the app faces customers rather than colleagues. What you are buying is not the drag-and-drop — an agent gives you components faster — but the auth plugins, the deployment pipeline and a set of defaults chosen by people who have watched this exact failure happen. Given the plan restructure, price it properly before committing: with code export and self-hosting, the workspace plan may be all you need.
$39/mo is cheaper than your weekend.
The backend is the asset and it already outlives the frontend, which is the one genuinely good thing about this architecture. Keep the schema, the policies and the migrations in version control so the database is reproducible without the app, and keep the frontend disposable — no business rules in components, no data transformations that exist nowhere else. Done that way, replacing your build with WeWeb, Retool or a rewrite is a rendering job rather than a migration. The thing to write down before you leave is which policies protect which tables, because that knowledge is currently in your head and nowhere else.
Large open-source low-code platform for internal applications and data sources.
React framework for CRUD-heavy internal tools and admin panels over any backend, with auth and access-control providers as first-class pieces.
Questions
If the backend enforces everything, is the frontend really risky?
That is exactly the condition under which it is not, and it is why the shipItIf list opens with it. The risk is that the condition is easy to believe and hard to verify. The app works either way, so nothing tells you which world you are in until somebody tries the API without your app in front of it. Test with curl and the anon key; that fifteen-minute exercise is the whole difference between the two verdicts.
Why is this harsher than Bubble or the other no-code entries?
Because of where the data lives. A platform that owns its own backend also owns the default that keeps a table private. WeWeb deliberately does not — it points at your Supabase or Xano and expects you to have configured it — so the self-built equivalent inherits an architecture where the frontend talks to the database and the only thing between a stranger and your customer table is a policy you wrote while trying to get a demo working.
What is the single highest-value hour here?
Open a terminal, take the anonymous key out of your own frontend, and try to read every table in the database with it. Then try to write to them. Most people discover something in that hour, and everyone discovers it more cheaply than the alternative.
- GDPR Art. 5 — principles relating to processing of personal data (EU)
- GDPR Art. 32 — security of processing (EU)
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
An internal tool is just a production database with a friendlier delete button.
Generating maintainable mobile code from a schema is the thing every team has tried and abandoned.
A no-code platform is a programming language with a GUI. You are writing a compiler.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice