People ask me some version of "how much for a booking app?" and the honest answer is that "booking app" covers two very different builds. They look the same in a mockup. They are not the same amount of work.
Here is how I break it down when I scope one.
The two versions
1. Request and confirm. A customer picks a slot and sends a request. You get notified and confirm it yourself. No online payment, no outside services.
2. Payment and reminders. Customer accounts, an admin side, online payment, a calendar or reminder service, and messages sent on a schedule in the background.
In my scope estimator, the first one lands at $3,500 to $5,500 over about 3 to 4 weeks. The second lands at $6,500 to $9,000 over about 4 to 5 weeks. Those are estimates from fixed rules, not quotes, and they assume a web app that works well on phones, not native iOS and Android apps.
Why the jump is so big
The screens barely change between the two versions. What changes is the number of outside services the app depends on.
Every outside service, like a payment provider or a text-message API, brings the same chores:
- setting it up and handling its webhooks
- deciding what happens when it fails or times out
- testing against the real service, not just a mock
- edge cases: refunds, double bookings, a reminder sent for a cancelled slot
One or two of those services is enough to move a build up a tier on its own. That is usually the line between "small app" and "real product".
What pushes the cost up
- Staff with their own calendars and permissions
- Several locations, services or price rules
- Sync with more than one outside calendar or tool
- Deposits, refunds and no-show fees handled inside the app
- Native mobile apps
- Health records or other regulated client data
Past a point (several locations, several outside systems, regulated data) I stop giving a range at all and scope it properly first.
What you can cut for a first version
- One location and one list of services
- Confirm requests yourself at first
- Take payment in person until demand is proven
- Email reminders before text messages
- One calendar to sync with, or none
- Packages and memberships in a second round
A lot of first versions can start as version 1 and grow into version 2 once real customers are using it.
Check this before paying anyone
For booking specifically, look hard at off-the-shelf scheduling tools first. If one of them covers your rules, it will be cheaper than any custom build, mine included. Custom makes sense when your rules are the product: unusual pricing, multi-step flows, or booking that sits inside a bigger app.
Also budget for
Payment and messaging providers bill their fees to your own accounts, on top of the build. Hosting too.
The full breakdown for booking apps, with FAQs, is here: harjotrana.com/cost/booking-app. If you want a number for your own idea, the free scope estimator uses the same rules.
Happy to answer questions in the comments.
Top comments (1)
Good split. The other line that moves cost is what happens when things go wrong: cancellations, no-shows and refunds. Clients rarely mention them in the brief, but they need rules on day one. Disclosure: we build a WordPress services marketplace plugin at Wbcom, and that part always takes longer than the booking flow itself.