Needed clients to see only their own tickets, without a wall of permission code.
Situation
A support desk served many client companies from one system. Staff needed an internal board; each client needed a portal showing only their own tickets.
The obvious approach was to check permissions in every screen and API route. With dozens of routes, one missed check would leak another client’s data.
Live updates, reporting and future integrations all needed the same isolation, so it could not live in one place in the application code.
What was built
- Designed the authorization boundary into the database using row-level security policies, so the rule “you can only see your own company’s tickets” holds for every query, every screen and every real-time update.
- Built an internal kanban board for staff and a separate client portal, both reading from the same isolated data.
- Wrote an automated policy test suite that proves each isolation rule, so a future change cannot silently open a gap.
- Planned the migration from the previous no-code tool so existing tickets and history carried across.
What held up
- Clients see exactly their own tickets and nothing else, enforced below the application rather than in it.
- New features inherit the isolation for free, which shortens every future build.
- The test suite catches regressions before they reach production.
What I would do differently
- Delete the identity-spoofing preview switch on day one rather than carrying it into the first build for convenience. Workarounds from the old platform can be backdoors.
- Use the vocabulary from the live data from the start. The spec’s status, priority and effort lists were invented; the real ones won and cost a migration.
- Write the row-level security policies and their test suite before any screen. They ended up being the architecture; everything else was faster once they existed.
Stack
Next.js, Supabase (Postgres, row-level security, realtime), pgTAP, Vercel