One database, many shops
Chairhouse is a booking and loyalty product for barbershops. The hard part was never booking. It was making one database serve many shops without any shop ever seeing another's data.
Client: Chairhouse.
Booking is a solved problem. Anyone can build a calendar. The part that decides whether a multi-tenant product is safe to sell is whether shop A can ever see shop B, and the honest answer for most small SaaS is that nobody has actually checked.
The rule here is that tenant isolation lives in the database, not in the application. Every table carries its tenant, every query is filtered by a policy the database enforces, and the application cannot forget to add a WHERE clause because the database will not serve the row regardless. If the isolation is written in application code, then one missed filter in one endpoint exposes everything, and that endpoint will be written on a Friday by someone in a hurry.
Payments settle to each shop directly rather than passing through us, which removes an entire category of problem: we never hold anyone else's money, so we never have to account for it, and a shop leaving takes its payment relationship with it.
First tenant was live five weeks from an empty repository.