Full Stack project
Build a multi-tenant SaaS dashboard
A logged-in dashboard where every user sees only their own account's data — the scoping bug that causes the most common real SaaS security incident.
The brief
Build a small SaaS app: signup/login, a dashboard that shows data scoped to the logged-in account only, and full CRUD on one resource (e.g. "projects" or "tasks"). Seed at least two separate test accounts and prove, in the README, that one account's data is never visible or editable from the other's session.
Suggested stack
What you hand in
- A public GitHub repository with the running app (frontend + backend) and a README
- The README documents how to run it and includes the two-account scoping proof (steps or a screen recording description)
- A short section naming one trade-off made in the data model
Grading happens against the rubric below, so read it before you start — not after.
How this is graded
Published in advance and weighted out of 100. Nothing here is a surprise.
Every query that reads or writes a resource filters by the logged-in account/user id at the server, not only by hiding UI elements. Account B genuinely cannot fetch account A's data by ID.
Create, read, update, and delete all work end to end and reflect correctly in the UI without a manual refresh being required to see accurate state.
The frontend and backend have a clear contract; the frontend doesn't quietly duplicate business logic that belongs on the server.
Loading, empty, and error states are all handled — the app doesn't look broken on a slow network or with zero data.
No console errors or crashes, no broken layout, no leftover placeholder text or commented-out code.
Why this project is worth your weekend
- Owning a feature end to end, from database to UI, is what "full-stack" actually means on the job, not knowing two separate frameworks in isolation.
- Cross-account data leakage is one of the most common real SaaS security incidents, and it happens exactly when scoping is done in the UI instead of the query.
- An interviewer can log in as account B and try to fetch account A's resource by ID directly against the API to check this in under a minute.
Where people lose points
- Filtering data by account only in the frontend (hiding rows) while the API itself will return any account's resource by ID.
- Keeping all state in frontend memory so a page refresh loses data instead of re-fetching from the server.
- No loading or error state, so a slow request just shows a blank or frozen screen with no indication anything is happening.
Other Full Stack projects
Two or three of these turn an empty resume into a portfolio.
Built it? Get it scored against this rubric.
Submit your work and get a score on every criterion above, written feedback, and three resume bullets you can use straight away.