02.2Major Project / Lead Developer6 sheets
Steady: Student Guidance and Counselling Platform
A web platform for a school’s guidance and counselling office. Students book sessions with their department’s counsellor, check in on how they are feeling, and get articles and playlists picked for that mood. Counsellors decide on requests and keep their own schedule. Administrators run accounts, publish content, and watch the service on a dashboard.
The public landing page, open to visitors without an account
Sheet 1 of 6
Sheet 1 of 6. The public landing page, open to visitors without an account
- Tech stack
- Next.js
- React
- TypeScript
- Supabase
- PostgreSQL
- Tailwind CSS
- shadcn/ui
- Radix UI
- TanStack Query
- Zod
- Cloudinary
- Vitest
- GitHub Actions
- Vercel
- Skills
- System design
- Database security
- Real-time systems
- UI/UX design
- Accessibility
- Context
- Guidance and counselling ran on paper. Records were retrieved by hand, and booking a session meant walking to the office in person — an extra step some students found uncomfortable enough to skip, on top of the waiting it caused. There was also nowhere central to send announcements from. Counselling records are confidential, so any digital replacement had to keep a student’s information private from other students, and from staff not involved in their case.
- Role
- Lead developer, on a team of five, submitted as a project research paper in December 2025 — with Gerlie Campion, Francis Adrian Esteban, Jhey Gulde, and Kathleen Grace Gultiano.
- Timeline
- About 4 months.
- Approach
- Three roles — student, counsellor, admin — that get genuinely different areas rather than the same screens with buttons hidden. Students book, reschedule and cancel; counsellors accept, decline and complete requests and set their own working hours; admins manage accounts, publish content and read the dashboard. Reads are plain functions that work the same in a server component or a query hook, and every write is a server action that checks the role and validates against the same schema the form used.
- Confidentiality
- The access boundary lives in the database rather than the interface. Row-level security on every table means a counsellor sees only the students in their departments and a student sees only their own records. Guard triggers cover what the UI cannot be trusted with — a student cancelling only their own booking, a held slot refusing to be double-booked, nobody but an admin moving a student between departments. Notifications are created only by database triggers, so no client can forge one, and they arrive live over a websocket. A 29-check SQL suite runs against the database as each role to prove all of it holds, alongside 73 unit tests in CI.
- Interface
- Everything is built on a documented design system — semantic colour tokens, a set type scale, and 17 shared components — which is what made a full dark theme a token swap instead of a rewrite. Loading, empty and error states are all drawn differently, so a failed load never reads as an empty list, and skeletons follow each page’s real layout. Contrast is checked by script before any colour change.
- Outcome
- We pitched it to the guidance office and they approved it, but it was never deployed — it was a school project, and development stopped after submission. It is up as an early-access demo running on sample data, with a notice saying so and confirming it isn’t affiliated with any university. You can click through it.