The work around an appointment
A salon booking system connects public booking with staff schedules and availability, governed by permissions. Clients and staff need different views of the same operation. Recurring appointments add work beyond the booking screen, as do calendars and waitlists.
What I built
I designed the product and system architecture, then built the web application and API alongside the background worker. The delivered scope includes staff web and public booking, with an operations console. I also worked on the native SwiftUI application.
My work covers product decisions and implementation across those clients. Scheduling depends on availability and permissions, so the system connects them.
Sharing data across clients
Next.js provides the web layer and Fastify the API. PostgreSQL/Drizzle and shared TypeScript support a common data model across the web application and API, including the worker, for multi-tenant operations.
Scheduling connects through the API, including recurring appointments and calendars, along with waitlists. Role-based permissions govern access to operational workflows. The native client provides another interface to that system.
What still needs measuring
The next useful check is how these workflows perform in daily use. That includes the work staff do around an appointment and the public booking experience. Production deployment alone does not show that staff workload has fallen or booking outcomes have improved.
Discuss the work
Tell me what your team needs to build, or where the work is getting stuck.