A client came to me with a booking app that was already built and already live.
Three salon businesses in Sweden were using it, and it kept double-booking customers.
Two people open the same time slot. Both see it as free.
Both book it. Then two customers turn up for the same chair, and a receptionist has to tell one of them to go home. It’s a small thing in the data and a big thing at the counter.
He didn’t want it rebuilt from scratch. He wanted it fixed, without the three businesses losing a day of bookings. That’s the job I took on.
I’ve built and fixed enough booking systems to know where to look first, so here’s what was actually going on.
Nothing was missing from the app. The time slots were there. The lists refreshed. The checks that should stop two people booking the same slot existed. But the app was slow, so by the time a check finished, the next person had already booked.
The real problem was balance
Every app is a balance between three things: how it looks, how fast it runs, and what it does. Push too hard on one and the other two suffer.
This app was built to look good first. Heavy screens, a lot on each one, lists refreshing constantly to keep everything current. All of that made it slow. And once it was slow, the booking check couldn’t keep up with real people tapping at the same time.
So the double bookings weren’t a missing feature. The app just couldn’t finish one job before the next person arrived.
What I changed
Almost everything underneath, while the front of it stayed exactly where it was.
The app wasn’t reading availability properly to begin with, and the actions on the booking button were saving the booking regardless. I fixed how availability is read, then restructured the actions so the check runs first and finishes before anything is saved.
Then I went through every screen and took the weight out of it. Lists now pull only what they need through their own filters, instead of loading everything and hiding the rest. Refreshing only where it earns its place. Images compressed. And I rebuilt the flow the staff use, because a receptionist was going through four screens to take one booking.
The app still looks as good as it did. It’s just not paying for it anymore.
What I want other builders to take from this: none of it needed anything exotic. Filtered lists, custom actions in the right order, and Adalo’s own components did the whole job. Everything I needed was already in the editor.
Open heart surgery
This is where the title comes from, and it’s the part that made the job difficult. Three salons were taking real bookings every hour of every working day. There was no taking it down, no maintenance window, no starting over.
Every change had to go in underneath a running business, in an order that never left the app in a broken state. One bad step during opening hours and three businesses stop taking money.
It went in without a single hour of downtime. Publishing in Adalo is fast, so I could move in small steps, watching each change land on a working app. That’s what made a rescue of this size possible on a business that couldn’t close for a weekend.
Where it is now
The double bookings stopped, across all three businesses.
And the bookings themselves have roughly tripled, to around 150 a day. Nothing else changed in that period, no marketing, no new locations, no new salons. The app simply stopped losing people halfway through booking. When a booking takes seconds instead of feeling broken, people finish it.
Same app. Same platform. Same three salons. Three times the bookings.
The client is now moving to the next phase with me: an AI assistant connected to the app’s database, reading each barber’s availability fast, showing it to the customer in chat, booking the appointment, and putting it straight on their bookings page.
What I’d tell any builder
If your app is carrying a real business, the balance between how it looks, how fast it runs and what it does isn’t a detail. It’s the whole thing.
Everything this app needed was already in Adalo. What decides whether an app holds up at 150 bookings a day isn’t which features you reach for, it’s how you arrange them, and that only comes from having built for that volume before.
If your app is heading that way, get the structure looked at early
rather than after the first bad week. That’s what the Adalo Expert is
there for.
The app is live if you want to see it. It’s published for the
Swedish market only, so use the web version if you’re outside
Sweden:
App Store (Sweden): Appen BokaNu – Boka Klipptid – App Store
Web app: BokaNu
If you liked this one, here’s a bigger build I wrote up: How I Built a $65,000 Marketplace App in Adalo: The Decisions That Mattered
And if your booking app is misbehaving, or you want one built properly the first time, that’s my work. 180+ apps shipped for clients in the US, UK and Australia.
My Adalo Expert profile: adalo.com/experts/ali-bazzi
Ali Bazzi
Adalo Expert & Community Leader