A Booking and POS Platform the Franchise Owns
How we're helping a 50-location wellness franchise replace its vendor booking and POS system with one it owns, moving each location only after every order, membership, and balance reconciles to the cent.
~50
Franchise locations in scope
8 yrs
Of pilot-location history migrated
$0.00
Revenue variance at the pilot location
CLIENT OVERVIEW
A wellness franchise with about 50 locations, where members pay on recurring monthly plans. The pilot location alone holds 21,389 client records and 2,132 memberships. Every spa ran booking, checkout, memberships, and client records on one vendor's platform, with about five other tools around it. The franchisee council had already spent months designing the system they wanted. What they needed was someone to build the engine underneath it and move eight years of history across without losing a booking, a membership, or a card.
THE PROBLEM
What was broken
A platform they'd outgrown, on terms that wouldn't bend
The booking and POS vendor wouldn't offer flexible terms, and the franchise was paying for a platform that no longer fit how it wanted to run. Owning the system meant owning the data, the roadmap, and the cost.
Migration mistakes would hit members directly
Memberships bill every month. A wrong balance, a lost appointment, or a dropped card means an angry member at the front desk. The leadership team said it plainly: they could not get data migration wrong, and they could not get card migration wrong.
Cutover had to happen one spa at a time
Each location runs its own front desk, rooms, and member base. Switching every spa on the same night would put the whole franchise at risk, and running two systems side by side would double the front desk's work. Every location needed its own clean, rehearsed cutover.
THE GOALS
What success looks like
Replace the vendor as the system of record for booking, checkout, memberships, and client records
Migrate every location's history with revenue, memberships, and appointments matching exactly
Cut over one location at a time, overnight, with no member re-entering a card
Build every section agent-ready so AI coaching can ship in phase two
OUR APPROACH & SOLUTION
Building the engine under a design the franchisees already approved
The client's team and franchisee council had designed the product. We owned the architecture, back end, data migration, and infrastructure, and worked alongside their in-house developer, who built much of the front end. Every section got a review call before it was built, and every architecture call was written down as a decision the client could read.
Phase 1
Data Model and Pilot Migration
Starting from the client team's map of the vendor's 161 data entities, we ran the pilot location's full history into a PostgreSQL database: 568,376 rows from three sources. Revenue, membership states, future appointments, and stored-value balances matched the source exactly.
Phase 2
Continuous Sync with Reconciliation Gates
We turned the one-time import into a scheduled sync that refuses to publish data unless it reconciles. The gate earned its keep early. It caught a timezone mismatch between the two systems and a bug in our own sync that loaded only 575 of 8,140 stored-value balance rows, and it held both back until they were fixed.
Phase 3
Cloud Infrastructure
We stood up staging and production on AWS with infrastructure as code, alarms on silent sync failures, and a login gate limited to company accounts. Adding a location takes about half a day.
Phase 4
Booking Calendar and Checkout
We built a calendar that mirrors the live vendor schedule room by room, then front-desk booking and Stripe checkout on top of it, from first click to a paid, receipted ticket. The full flow runs end to end on staging, and the production launch is planned for 2027.
WHAT WE BUILT
Features and capabilities
01
Reconciled Continuous Sync
Every 15 minutes, a scheduled job pulls each location's clients, appointments, orders, memberships, balances, hours, and room schedules from the vendor into PostgreSQL. Reconciliation checks compare revenue, order counts, and memberships against the source, and data a failed check protects is held back instead of published. An alarm fires if about 6 hours pass without a clean run.
02
Full-History Location Import
One command loads a location's full history, about 570,000 rows for the pilot spa, in about 4 minutes. The import is safe to re-run, so each spa can rehearse its cutover as many times as it needs before the real one.
03
Live Room-by-Room Calendar
The calendar mirrors the vendor's schedule for each treatment room, including bookings, blocked time, and open start times, and shows when it last synced. It runs in production and matched 690 and 1,084 room shifts exactly at the first two spas.
04
Front-Desk Booking
Staff book a guest or a whole party across rooms at one start time, and move a booking by dragging it. Every tile shows whether it came from the vendor, the platform, or the AI receptionist, and the day refreshes every 30 seconds. We built the booking engine and calendar logic, and the client's developer built the booking screens.
05
Stripe Checkout and POS
The front desk checks a ticket out against the plans, promotions, packages, retail items, and tax rate in settings, and finishes with a paid, receipted Stripe charge. Each location runs its own Stripe account, and nobody is charged at booking: the card is saved, and the charge happens when the session ends. We built the payments core, and the client's developer built the checkout screens.
06
Client Profiles on Real Data
The client list and profile read synced data, with tabs for waivers and consent, billing, and intake, so the desk can answer a question about a guest without opening the vendor's system. We and the client's developer split the profile tabs between us.
07
Settings the Spas Run On
Settings hold each location's services, hours, rooms, promotions, and retail items, which booking and checkout read directly. Staff can take a room out of service for a set window without touching the schedule. The client's developer built the settings screens, and we built the data and API underneath them.
08
Cloud Infrastructure and Access
Staging and production run on AWS, defined in code, with containerized services, a managed PostgreSQL database, and alarms on the sync. Sign-in is limited to the company's own Google accounts, and adding a location takes about half a day of hands-on work.
KEY TAKEAWAYS & IMPACT
What changed for this business
72,871
Orders reconciled to the cent
The pilot location's full order history, $3.56M in revenue, matches the source system to the penny and to the order count. That is the bar every location has to clear before it switches.
~4 min
To import a location's full history
About 570,000 rows for one location, eight years of appointments, memberships, payments, and balances, loaded and reconciled in minutes. Re-running it is safe, so the cutover rehearsal is the same command as the cutover.
12
Locations syncing live
Twelve spas sync from the vendor every 15 minutes, and the calendar mirror reconciled 690 and 1,084 room shifts exactly at the first two. The same synced data feeds the franchise's AI receptionist in production.
THE OUTCOME
What it's built to deliver
-
Each location switches only after its revenue, memberships, appointments, and balances reconcile against the vendor, so a migration error is caught before a member sees it.
-
The cutover plan moves saved cards from the vendor to Stripe through Stripe's migration team, so members aren't asked to re-enter a card.
-
Each spa cuts over on its own schedule, and the rehearsal is the same command as the real import.
-
The front desk sees vendor, platform, and AI receptionist bookings on one calendar, each labeled by source.
-
The franchise owns its booking and client data, its product roadmap, and its software costs.
-
The sync and calendar mirror already run in production for 12 locations, where they feed the franchise's AI receptionist.