Scheduler — Shared Space Booking

Production web app for booking shared amenities and rooms: monthly calendar, whole-day reservations, multi-amenity selection, conflict prevention, and admin-controlled access — live at bookamenities.com.

Role: Full Stack Engineer — product UX, booking logic, auth API, admin workflows

React

TypeScript

Vite

Tailwind CSS

Express

Argon2

Live demo

Problem

→Communities and property managers need a simple way to reserve shared spaces (amenities, rooms) without double-booking the same resource on the same day.

Architecture decisions

→Whole-day bookings only (Mon–Sun monthly view) to match real amenity usage, not hourly complexity
→Multi-amenity selection per reservation with per-amenity conflict checks
→Spanish-first booking form with validation and sensible optional fields
→Split persistence: server DB for identity/auth, localStorage for bookings until full backend migration

Backend design

→Express auth service with session cookies and Argon2 password hashing
→Signup creates pending users; login restricted to admin-approved active accounts
→Auth tables persisted in server database; booking/amenity CRUD currently client-side

API structure

→Session-based auth endpoints (signup, login, logout, session check)
→User lifecycle: pending → active (admin approval required)
→Future-ready separation between auth API and booking domain

Database design

→Server: user/auth tables (sessions, credentials, approval status)
→Client (today): bookings and amenities in browser localStorage
→Conflict model: unique (amenityId, date) enforced in application layer

Scalability

→Clear path to move bookings/amenities from localStorage to server persistence
→Conflict rules already centralized for extraction into API transactions
→Static frontend deployable to CDN; auth API scales independently

Authentication

→Express sessions with HTTP-only cookies
→Argon2 password hashing (no plaintext storage)
→Admin-gated signup: pending users cannot log in until approved

Deployment

→Production frontend at bookamenities.com
→Express auth API deployed alongside SPA
→Tailwind-based UI shipped as optimized Vite build

Challenges

→Dual persistence model (auth on server, bookings local) requires careful UX around data portability
→Whole-day conflict logic must stay correct when multiple amenities are selected in one form
→Bilingual/Spanish form copy with validation messages that remain accessible

Lessons learned

→Ship a focused scheduling product before adding hourly slots or payment complexity
→Auth and domain data can evolve on different timelines if boundaries are explicit early
→Admin approval workflows are cheap to build and prevent abuse on shared-space apps