Zapys24CRM and Online Booking for Service Businesses
One platform for salons, garages, gyms and stables
SaaS for service businesses: 24/7 online booking, client base, staff and reminders. The platform adapts to the industry — from beauty salons to riding clubs.
Challenge
Service businesses need booking without calls and DMs, but a salon, a garage and a stable book completely different things: a stylist, a bay or a horse.
Result
A multi-tenant platform where a booking reserves a set of resources, not just a person. Double bookings are rejected at the database level, clients get reminders, and the business runs everything from the web or the app.
Key features
24/7 online booking
Industry resources: staff, bays, horses
Double-booking protection
Automated reminders
Client base
Staff & schedules
Memberships
Mobile apps
How it's built
A booking CRM that a beauty salon, a car service and a riding club can all run from the same codebase — a public booking page, a business app and a client app on one API. These are the decisions that shaped it.
50+
Backend modules
129
Schema migrations
2
Mobile apps, one API
24/7
Self-service booking
Industry is a field, not a fork
Every business carries an industry code, kept deliberately separate from the beauty-specific business type. Terminology, form sections and the booking rules are read from an industry config; the booking service picks its strategy from a registry keyed by the same code.
That one decision is what lets a riding club and a nail studio share a deployment. Resources are generic — a chair, a stall or a lift are the same entity with different words around them — and beauty stays the default, so adding an industry changes nothing for the businesses already running.
The same platform, dressed for a riding club
Two clients cannot take the same slot
Creating a booking opens a transaction and immediately takes a PostgreSQL advisory lock on the staff member and on every resource involved, each key prefixed by class so a staff id and a resource id can never collide. Only then does it check for overlaps.
Resources carry capacity: a resource counts as busy only once overlapping bookings reach that number, so a room for eight is not blocked by the first person who books it. All the interval, buffer and overlap maths runs in business-local minutes, which is what keeps it correct across time zones.
The business keeps its own money
Prepayments do not pass through the platform. A business connects its own monobank merchant credentials, stored per business, and invoices are raised against that account; LiqPay is the alternative.
The platform therefore never becomes a payment intermediary — nothing to hold, nothing to pay out, no regulatory role that a booking product has no business taking on. The money lands in the salon's own bank.
Reminders are the product
Notifications are split by channel — booking, business, platform, social — so a client can mute marketing without losing the reminder about tomorrow's appointment.
Email renders from Handlebars templates, push goes through Firebase, and SMS runs against a per-plan quota, because SMS is the one channel that costs real money per message. Telegram carries operational alerts to the team, never to clients.
Notifications and reminders — the part businesses actually pay for
A booking site without a web developer
Each business can publish its own booking site from a template. The template itself lives in code — palette, fonts, block layout — because design changes together with the renderer, not separately from it. The database stores exactly one thing about it: the lowest plan that may publish it.
Disabling a template removes it from the picker without taking down the sites already published on it. That asymmetry is deliberate: an admin tidying up the template list should not be able to switch off someone's working site.
Subscriptions on three fronts
The same subscription has to work when it is bought on the web and when Apple sells it inside the app. Web billing runs through the platform's own plans and add-ons; in-app purchases are verified server-side against Apple's App Store Server library, so the entitlement comes from the receipt rather than from the client.
Plans compare by rank, not by name — otherwise every feature check would list "basic" and "pro" by hand and drift apart the first time a tier is added.
What production demanded
Background work runs on Bull queues over Redis, which also carries the cache. Media goes to S3-compatible storage and is resized with sharp on the way in. Sessions are signed and cookie-based, passwords hashed with argon2, endpoints rate-limited, health exposed through Terminus and the API documented in Swagger.
The unglamorous parts — Excel exports for accountants, staff payouts, expense tracking, a support desk — are in because a CRM that a business runs its day on cannot stop at the calendar.
The result
A booking platform in production at zapys24.com: a web cabinet, a client app and a business app on iOS and Android, with two industries live and the model ready for the rest.