Systems · Product design and full-stack build
Bookyra - Salon Scheduling Platform
Salon reservation platform for beauty professionals, with schedules, reminders, invoicing, public profiles and operator dashboards.
Overview
Bookyra is a scheduling platform for beauty professionals and salons. We designed and built it: public salon profiles, service schedules, client reservations, SMS reminders, team and role management, reviews, subscription invoicing, and the operator dashboard that ties them together.
Business context
Beauty professionals run their scheduling across a phone, a paper diary, a social media inbox and a separate payment method. Each tool works; none of them know about each other. The result is double bookings, no-shows that nobody reminded, and an owner who cannot see what the business did last month without adding it up by hand.
The challenge
The platform had to be simple enough for a client booking an appointment on a phone in under a minute, and complete enough for a salon owner managing several staff, their individual schedules, their services and their permissions. Products usually resolve that tension by being good at one end and unusable at the other. It also had to be genuinely multi-tenant, because every salon needs its own data, its own staff and its own public presence within one system.
UX and interface
The client flow is deliberately short: choose a service, see who can do it and when, pick a slot, confirm. The salon side is organised around the calendar, because that is what an owner opens first and returns to all day. Team, service and permission management sit behind that rather than competing with it for attention. States that matter operationally - pending, confirmed, cancelled, completed - are distinguishable at a glance rather than by reading.
Development
Built in React and TypeScript as a multi-tenant application. Authentication, role-based access control and tenant scoping are foundational rather than layered on. Scheduling logic handles per-staff availability, service duration and conflicts. Subscription invoicing manages the plan lifecycle, including the states that generate support requests - failed payments, plan changes and cancellations.
Architecture and integrations
One data model with tenant scoping applied at the access layer, so a salon's data cannot be reached from another tenant's session regardless of what the interface requests. SMS delivery and subscription invoicing are integrated as external services, with the application recording the delivery and billing state rather than assuming success. The reservation lifecycle drives notifications, so a reminder cannot be sent for an appointment that was cancelled.
Performance and search
Public salon profiles and the marketing pages are server-rendered with unique titles, descriptions and headings, so they can be indexed and shared as real pages. Everything behind authentication - dashboards, team management, invoicing - is excluded from indexing and kept out of the sitemap, so crawl budget goes to the pages that can actually attract clients.
What was delivered
A single platform covering scheduling, reminders, team management, reviews and subscription invoicing, replacing a set of disconnected tools, with the multi-tenant structure and invoicing needed to operate it as a product. We have no verified figures on adoption, retention or revenue to publish.
Scope
- Multi-tenant account and permission structure
- Public salon profiles and service listings
- Service scheduling and staff availability
- Client reservation flow
- SMS reminders
- Team and role management
- Reviews
- Subscription invoicing
- Operator dashboard
Strategy and key decisions
Two products, one system
The client-facing side and the salon-facing side were designed as distinct products with distinct goals - speed of booking versus depth of control - sharing one data model. Trying to serve both from a single interface is the usual failure mode in this category.
Permissions in the data layer
Tenant separation and role rules are enforced where the data is accessed, not in the interface. An interface that hides a control is a suggestion; a rule at the data layer is a guarantee, and in a multi-tenant product that distinction is the whole security model.
Reminders as part of the booking, not an add-on
No-shows are the cost the business actually feels, so SMS reminders were built into the reservation lifecycle from the start rather than added later as an integration that can silently stop firing.
Public profiles as the acquisition surface
Each salon's public profile is a real, server-rendered page rather than a view inside an application, so it can be linked, shared and found - which makes the platform useful for getting clients rather than only for managing them.
This write-up describes work delivered and capabilities built. It does not report traffic, conversion or revenue figures, because we do not have verified post-launch measurements to publish.
Have a similar project?
Tell us what you want to build and we will come back with a clear, honest plan.