The Problem
SEA Salon is a salon management system for a growing business that needs to handle online bookings, stylist scheduling, and multi-branch administration. The core pain point is managing conflicting reservations: clients need to book a specific stylist at a specific time, and the system must reject bookings that clash with existing appointments. Without this, the salon risks double-bookings and scheduling chaos as its clientele grows.
What This Does
The app is a full-stack Next.js application with a React frontend and a PostgreSQL database accessed through Prisma. Public-facing pages (app/home/page.tsx, app/service/page.tsx, app/branch/page.tsx) let users browse services and branches, while authenticated users can book appointments. The booking flow (components/Booking/booking.tsx) lets users pick a branch, stylist, services, and time; the backend checks for conflicts via the API routes in app/api/booking/.
Admin functionality lives in the dashboard (components/Dashboard/Dashboard.tsx), backed by a set of CRUD API routes under app/api/admin/ for managing branches, services, stylists, reservations, and reviews. Authentication is handled by NextAuth (lib/auth.ts), with role-based gating. The app/api/middleware.ts enforces admin-only access to management endpoints.
How To Use It
Setup: Clone the repo and install dependencies with npm install. The project uses npm (see package-lock.json). Prisma migrations are in prisma/migrations/ — run npx prisma migrate dev to apply them to a local database.
Configuration: Create a .env file from .env.example. Required variables are DATABASEURL, NEXTAUTHSECRET, CLOUDINARYCLOUDNAME, CLOUDINARYAPIKEY, CLOUDINARYAPISECRET, NEXTPUBLICCLOUDINARYAPIKEY, and NEXTPUBLICCLOUDINARYCLOUDNAME. The README includes a development .env with real credentials — do not use these in production.
Running it: Start the dev server with npm run dev and visit http://localhost:3000. Seed data is available via prisma/seeds/seed.ts. The app is also deployed at sea-salon-six.vercel.app.
Real-World Use
A client visits the site, selects a branch, picks a stylist and a time slot, and books a service. The API checks the Reservation table for conflicts on that stylist's schedule and returns an error if the slot is taken. An admin logs in, opens the dashboard, and adds a new service or edits a stylist's price without touching code. The system also handles image uploads through Cloudinary, so the salon can update service photos without a developer.
Code Health & Issues
High - Hardcoded secrets in README: the .env block contains a live database URL and Cloudinary API keys. Anyone who clones the repo gets production credentials. Med - No CI/CD pipeline: no .github/ directory or CI config exists, so there's no automated build or test gate before deployment. Med - No license file: usage and redistribution rights are unclear, which matters if the salon wants to commercialize this. Med - Admin UX requires manual page reloads after CRUD operations (noted in the README's "Restriction" section). This is a known limitation, not a hidden bug. Low - Only 2 test files exist, and they appear to be seed/reset scripts rather than unit or integration tests. The booking conflict logic has no automated coverage. Low - No input validation visible on API routes; the app relies on client-side checks, which is risky for a public booking endpoint.
The Bottom Line
This is a functional, well-structured salon booking system that demonstrates a solid grasp of Next.js, Prisma, and authentication. The booking conflict logic and admin dashboard are the standout features. The lack of CI, minimal tests, and exposed credentials in the README mean it's not production-ready without hardening. It's a good starting point for a small business or a learning project, but a team adopting it should add automated testing, a CI pipeline, and rotate the leaked secrets.