I build full-stack systems that actually ship.

The problem

The old site sold software. The revamp had to sell a point of view: Riyadvi as a technology and digital solutions partner, with a black-and-gold identity, real interactive 3D, and a backend that keeps every enquiry instead of losing it in an inbox.

What visitors can do

• Browse six services, each with its own page and its own 3D visual.
• Explore ten portfolio case studies, including 3D device presentations.
• Read the blog with search, categories and tags; filter job openings by department, designation and experience.
• Book a consultation, send a contact enquiry, and download the Software Project Planning Guide.
• Take the six-step Business Health Checkup and receive an instant readiness score.
• Apply for a job with a résumé upload handled by the API.

What the company gets

• Every form is validated and persisted in MongoDB.
• A protected /admin dashboard with totals, search, status tracking and résumé downloads.
• Optional e-mail notification on each submission via Nodemailer.
• Content is edited from a single data file — services, projects, articles and jobs change without touching page code.

How it's built

The Next.js frontend talks to a separate Node/Express API which owns all persistence in MongoDB. Phones get a lighter 3D scene, and any device that can't run WebGL receives a flat image instead of a broken canvas.

Engineering notes

The brief asked for at least four 3D and animation technologies. The project visibly uses seven: Three.js, React Three Fiber, Drei, GSAP, ScrollTrigger, Lenis and Motion. The backend carries 28 automated tests through Node's built-in test runner and Supertest. Claude generated the first version of the project; I reviewed it, restructured the API boundaries, fixed the auth and validation gaps, rewrote the admin permissions, and rebuilt the 3D performance path myself.

Architecture

• backend/ — Express + MongoDB REST API with JWT auth
• customer-web/ — React (Vite) booking app
• salon-dashboard/ — owner and staff dashboard
• admin-dashboard/ — platform-wide administration
• mobile-app/ — React Native (Expo) booking app
• marketing-website/ — static landing page

Four front-ends and one API. That was the central decision: every surface reads and writes through the same REST layer, so a booking made on the phone is visible to the salon dashboard without a single extra integration.

User flows

• Customer — register, discover salons by location/category/rating, review services, staff, hours and reviews, then select service → stylist → date/time → confirm, and manage or cancel bookings.
• Salon owner — stats and revenue, CRUD on services with pricing and duration, staff management with specialties and working hours, appointment lifecycle (confirm → start → complete), and salon settings.
• Admin — platform-wide revenue and appointment breakdown, user activation, salon featuring, and moderation over all reviews.

Engineering decisions

• Double-booking prevention — appointments are checked for time overlap before creation using MongoDB queries that compare start and end windows.
• Dynamic availability — the server generates time slots from staff working hours, approved leave and existing appointments, so the client never invents a slot the salon can't honour.
• Role-based access — the JWT carries the user role and middleware enforces permissions per route; the front-end nav only hides what a role can't do.
• Text search — MongoDB text indexes over salon name and description.
• Rating aggregation — salon and staff ratings recompute through an aggregation pipeline whenever a review lands.

Security

bcrypt password hashing, expiring JWTs, rate limiting at 200 requests per 15 minutes, Helmet.js headers, express-validator input patterns, explicit CORS configuration and role-gated routes. Secrets live in a local .env built from .env.example and are gitignored.

Why it exists

The front desk kept a paper register. Nobody could search a visitor history, approvals were a phone call, and no one could answer "who is in the building right now". Gatekeep turns that into a system and cuts check-in time by roughly 40%.

Roles & permissions

• Administrator — full dashboard, manages employees and user accounts, sees all reports and the global activity feed.
• Receptionist — registers, checks in and checks out visitors, sees reports and their own desk activity.
• Employee — sees and acts on their own visit requests, approving or rejecting them with remarks.

Every route is protected by protect (valid JWT) and authorize(...roles) middleware. The front-end nav hides what a role can't do, but the API is the actual enforcement point.

Ten business rules, all server-side

• A visitor cannot have more than one active visit (pending, approved or checked-in) at a time.
• No duplicate registration for the same visitor on the same date.
• Visit date cannot be before today; for same-day registrations arrival time cannot be in the past.
• An employee cannot hold more than 3 pending requests at once.
• Check-in requires prior approval.
• A checked-in visitor cannot be checked in again until checked out.
• Check-out time must be after check-in time.
• Rejected requests can never be checked in.
• Cancelled visits are excluded from active visitor lists.

Structure

Backend is MVC-shaped: models/ for Mongoose schemas, controllers/ for business logic including every rule above, thin routes/, and middleware/auth.js for JWT verification and role gating. The React front-end groups pages per role under src/pages/{admin,receptionist,employee} and shares building blocks — VisitorTable, VisitorFilters, StatusBadge, Modal — from src/components. An AuthContext holds the session; the axios instance attaches the JWT and redirects to /login on 401.