The table editor is great when I'm the only one touching the data. Then ops needs to update records, or a client wants to see their own rows, and suddenly I'm writing another list page, another form, another permission check. Same code every time, different table names.
So I tried the other approach: read the Postgres schema metadata and generate the resource UI from it. Add a column, the form picks it up. No per-table config.
The thing that made it usable for real business systems instead of just an internal dashboard was keeping authorization in Postgres. RLS policies and role/permission tables do the enforcement, so the frontend is only a client. Working around the UI gets you nothing. Audit history lives in the database too.
What it does past a basic table editor:
Stack: React 19 + Vite, TanStack Router/Query/Form/Table, shadcn, Supabase for auth, database, storage and edge functions.
There are example schemas in the repo (CRM, HR, inventory, helpdesk, a few others) mostly to check the generation approach holds up past toy scale.
Demo: https://jdydxqrxntcdrxhqqmuv.supasheet.app
Code: https://github.com/supasheet/supasheet
Disclosure: I built it. Posting mainly to find out what breaks it. If you have a schema that would be a nightmare here, composite keys, 200 column tables, deeply nested RLS, I want to hear about it.
The user describes a system that generates a business app UI from a Postgres schema, leveraging Supabase for auth, database, storage, and edge functions. The system supports various view types, conditional fields, and other advanced features, with authorization handled via RLS policies. The user seeks feedback on potential limitations or issues with complex schemas.
Get Started at https://supasheet.app