Salon and Spa Booking Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why do deposits and no-show protection get pushed to phase two?

Because they are the only part of the build that touches money, and money is where a development team is most likely to say let us do the simple version first. The simple version is a booking flow with no card capture, a confirmation email and a cancellation policy written in the footer. It demonstrates beautifully. It also means the front desk is still having the conversation about whether to charge someone, which is the conversation the software was bought to end.

The deferral is usually rationalised as a payment integration risk. In practice the integration is the easy half. The hard half is the policy logic: a deposit of 20 to 50 percent taken at booking, a card retained for the balance, a cancellation fee that varies by how much notice was given, a rule for what happens when a client cancels twice, and the automatic capture of the balance at checkout so the desk never handles a card again.

The fix is to write that policy before design begins and make it a first release requirement, not a backlog item. Ask your prospective developer to describe what happens when a client cancels 90 minutes before a colour service with a stored card and a 24 hour policy, and listen for whether they describe the charge, the notification, the record and the dispute path. If they describe a setting, the logic has not been thought about, and you will be building it later at a higher price.

What goes wrong when you migrate off Fresha, Phorest or GlossGenius?

Client records and appointment history export reasonably well. Gift card balances, prepaid packages, memberships and loyalty points do not, and those are liabilities you already took money for. A client who bought a six session package and finds three sessions in your new system will not accept an explanation about data mapping, and neither will a regulator if the amounts are large enough to matter.

The second failure is duplicates. The same client exists as an online booking, a walk in the desk typed manually and a third record created when they changed phone numbers. Merging them changes stylist history and therefore rebooking prompts, so the deduplication has to happen before any automated messaging goes live, otherwise your first campaign texts the same person three times.

The third is double charging during cutover. If both systems can take a payment for the same appointment during a parallel period, one of them will.

The fix is a migration phase with its own budget, its own reconciliation and a parallel run rather than a same day switch. Reconcile gift card and package balances to the cent before go live, freeze new package sales on the old platform during the parallel window, and make one system authoritative for payments on any given day rather than both. Ask any developer whether they have moved a live salon off a platform without losing balances or double charging clients mid cutover, and ask what went wrong when they did.

Why do the payment, point of sale (POS) and calendar integrations break after launch?

Payment integrations break at the edges nobody rehearses. A tip added on a terminal after the service has already been charged. A partial refund on a package. A card that declines on the balance capture when the deposit succeeded weeks earlier. A chargeback on a no-show fee, which is the one dispute type this category generates constantly and which needs your cancellation policy, the booking timestamp and the notification record attached to win.

Point of sale breaks because the ticket and the appointment are usually two different objects. A retail product added at the register has no idea which stylist recommended it, and a service performed by an assistant and a senior stylist together arrives at the register as one line. Once that structure is lost, your service mix, retail attach rate and commission numbers are all approximate.

Calendar sync breaks quietly and is the most common post launch complaint. Two way sync with personal calendars means a stylist's dentist appointment must block availability, and a change on the phone must not resurrect a slot already sold.

The fix is to make the ticket the atomic record, with line items carrying a service code, the performer per line, discount reason, tip allocation and tax category, and to treat the payment as an action against that ticket rather than a separate act of commerce stapled on afterwards. On calendar sync, insist on a documented conflict rule and a test that runs both directions, because a race between a personal calendar edit and a client booking is not a rare event in a busy salon, it is a weekly one.

What happens when med-spa intake, consent and licensing are not covered?

You end up booking a $400 injectable appointment through a system that treats it like a haircut, which is a clinical and commercial exposure rather than an inconvenience. The specific gaps are consistent. Intake forms and consent are collected on paper or through a separate form product, so the consent that matters is not attached to the appointment it relates to. Before and after photographs live in a phone gallery. Provider licensing and scope of practice are not modelled, so the booking engine will happily place a treatment with a provider who is not permitted to perform it. Treatment room and equipment availability are ignored, so two providers are booked into one room.

These are the reasons med-spa projects sit in the $80,000 to $120,000 and above band with 20 to 32 week timelines rather than the single location range, and a quote at MVP pricing for a med-spa has not read the requirement.

The fix is to model resources and permissions as booking constraints rather than as documentation. Rooms and equipment are bookable resources with their own availability. A provider carries qualifications with expiry dates, and an expired qualification removes them from the eligible list for that treatment before anyone can book it. Consent and intake are records attached to the appointment with a version, so you can show exactly what a client agreed to on a given date. Photographs are stored with access control and a log of who viewed them, and your handling of that data should be reviewed by counsel familiar with your jurisdiction rather than assumed.

Should you build custom or configure what you already own?

For a solo stylist or a two chair shop, stay on the platform. Fresha, GlossGenius and Acuity set up the same day, cost less than a single sprint and are genuinely good at converting a stranger into a booked appointment. Building at that size buys infrastructure you do not want to own.

Between those extremes, configure harder before you build. Phorest, Boulevard and Mangomint all have deeper operational tooling than most owners use, and a fair number of the complaints that trigger a build request are configuration problems: memberships never set up properly, deposit rules left off, resource scheduling unused. Have someone spend two weeks pushing your current platform to its limits and write down exactly what it refused to do. That document is either your business case or your answer.

There is also a genuine middle path. A custom booking front end on your own domain, wired to a scheduling engine you did not write, gets you the branded experience and the client relationship without rebuilding calendar mechanics from scratch. It sits at the lower end of the cost bands and keeps ownership of the part that matters, which is the client.

Build fully when three things are true at once: enough chairs that per seat fees sting, a client list you refuse to expose through a marketplace, and workflow edges the platform cannot bend to, which usually means med-spa consent, membership tiers or multi site reporting.

How do hidden costs get into the quote?

Through five doors. Migration is the first and the most consistently underpriced, because gift card and package reconciliation is careful accounting work rather than a script, and it needs your staff as well as the developer's.

Concurrency is the second and it is invisible until launch. Two clients booking the last slot at the same moment is a real event on a Sunday evening, and handling it correctly is engineering work that no demonstration reveals. Ask specifically how the system prevents a double booking under load.

Native mobile applications are the third. App store review adds calendar time on every release, and a mobile application commits you to ongoing maintenance as operating systems change. A well built web application on your own domain covers most of what owners actually want from an app.

Ongoing maintenance is the fourth and belongs in the business case from day one at roughly 15 to 20 percent of build cost per year, covering hosting, payment interface changes and support. The fifth is messaging compliance, because reminder and rebooking texts need registration and proper opt out handling, and that has lead time.

What separates a build that works from one that fails here?

Ask to see a booking flow they have shipped with deposits, split tips and automated no-show capture, in production, for a real business. This is the specific competence that decides whether the project pays back, and it is not a general web development skill.

Ask how they prevent two clients booking the last slot simultaneously. The answer should describe a locking or reservation mechanism, not optimism about how unlikely it is.

Ask how they would move a salon off Phorest without losing a gift card balance, and expect to hear parallel running, daily reconciliation and a rule about which system takes payment during the window. Ask what happens to a no-show fee that gets disputed, because the answer reveals whether they have kept the evidence you need to defend it.

If you are a med-spa, ask how provider licensing and treatment room availability constrain the booking engine, and treat a document upload field as the wrong answer. Then settle ownership before signing: the source code, the database, the repository and the cloud accounts in your name, with the client list unambiguously yours in writing. At Digital Heroes the client owns the code from the first commit. Escaping a platform that treats your clients as its inventory only to hand the same control to a development agency is a trade with no upside.