The problem
Salon operations bring together staff workflows, public booking, availability and permissions. Different users need different views of the same appointment model, and a native companion needs to fit the existing operation.
My role and delivery
I designed and built the product and system architecture, web application, API and worker, along with native application work. The delivered scope includes staff web, public booking, an operations console and internal SwiftUI clients.
Engineering scope
Next.js, Fastify, PostgreSQL/Drizzle and shared TypeScript support multi-tenant operations. Scheduling, recurring appointments, calendars and waitlists connect through an API and shared model. Permissions are part of the product scope, alongside the appointment interface.
The SwiftUI client remains in internal testing. A production web release does not imply that the native app is publicly distributed. This overview does not expose tenant records, appointments, customer information or operating configuration.
Evidence and limits
The public resume records production web, API and worker releases and internal iOS builds. The illustration is a feature study, not a screenshot of customer appointments. Production status establishes delivery, not an adoption count, revenue result or measured operational improvement.
There is no public performance benchmark or customer dataset attached to this case study. Native public distribution and shareable outcome evidence remain separate milestones.
Discuss the work
Hiring for a hands-on engineering leadership or applied AI role? Share the team, the scope, and the problem you need solved.