Commercial website · 2025 · Completed
99 AKTAU
A website for a PlayStation club, with guest booking requests and an admin area to manage them.
- Built for a paying client
- Live in production
- Source on GitHub
- Supabase database
- Admin authentication
Overview
A guest picks a hall and sends a booking request. The administrator opens it and accepts, rejects, or deletes it. The guest sees the updated status. The public site and the admin tools read the same booking data.
Context
This was my first commercial project. The club had no website and no way to take a booking other than a direct message. Both sides of the problem, the guest sending a request and the club answering it, had to be solved together or the site would only move the work somewhere else.
The problem
The club needed a public website and a practical admin area, not two separate tools holding different booking information.
The system, step by step
- Guest chooses a hall and sends a request
- The request is stored with a status
- An authenticated administrator reviews it
- Accept, reject, or delete writes back
- The guest sees the status that was set
Architecture
Public site and admin area in one Next.js application
- Next.js
- TypeScript
- Tailwind CSS
Booking requests stored with a status field
- Supabase
Admin routes behind authentication
- Supabase Auth
Production build with environment variables
- Vercel
Key decisions
Question
How much should the guest form ask for?
Keep the guest form short, ordered by what the guest already knows.
The administrator still needed enough to accept, reject, or remove a request without contacting the guest first. The form had to stop exactly at that line.
Question
Where does booking state live?
In a stored status on the request, not in browser state.
The guest and the administrator look at the same request from two different places. A status the server owns is what lets both sides agree on it.
Question
How do admin actions avoid mistakes?
Distinct labels for accept, reject, and delete.
The three actions have very different consequences. Similar wording is what makes them easy to confuse.
Question
One service or several?
Supabase for both storage and authentication.
It kept the number of moving parts and environment variables low on a project I had to deploy and hand over on my own.
What I built
A public site presenting the club and its halls, a booking request form, an authenticated admin area listing incoming requests, and status controls that accept, reject, or delete one. The status a guest sees is the status the administrator set.
What went wrong
The first working version broke on the way to production, not in development. Mobile form layouts, authentication state, environment variables, and build settings each had to be fixed before the deployed site behaved the way the local one did.
Outcome
Result
The public website and the admin tools work as one system. Guests send requests, and the club manages each one from the admin area.
What I learned
A commercial website is not finished when the public pages look correct. The owner also needs reliable controls, deployment settings, and clear handover notes.
Stack
- Next.js
- TypeScript
- Tailwind CSS
- Supabase
- Vercel