How much does a custom LINE booking system cost? We break the quote into seven parts
Custom LINE booking systems in Taiwan run from NT$45,000 to well over NT$100,000. The gap isn't about how pretty the screens are — it's whether the slot engine, reminder scheduler and admin backend were actually built. This article breaks the quote apart and shows you which parts you have to pay for and which you can cut from version one.
Let's start with the number:A custom LINE booking system in Taiwan typically runs from NT$45,000 to well over NT$100,000.
Two quotes for the same "LINE booking system" can easily differ by 3×. The difference isn't visual polish — it's how many of the seven parts below are included, and how far each one goes.
Once you've read this, you'll be able to ask the right questions of any quote you receive.
Part one: the LINE Official Account integration foundation
This covers Official Account setup, webhook message handling, signature verification, certificates and deployment.
This part is identical on every project, and it's the piece non-technical buyers most often underestimate — it produces nothing a customer can see, but without it nothing else works.Skip signature verification and anyone can impersonate messages into your bot.
It accounts for less than 20% of the quote, but when someone comes in unusually cheap, this is usually where the corners were cut.
Part two: the booking flow itself (the biggest piece)
Every step between "customer wants to book" and "booking confirmed": pick a service, pick a date, pick a time, confirm, leave their details.
It sounds simple. In practice it's the most labour-intensive part of the whole system, because it isn't a straight line — it's a graph:
- A customer drops out halfway and comes back three days later — do they resume or start over?
- A customer already has one booking — do you block a second or allow it?
- They pick a slot and find someone else just took it — how do you send them back a step?
- They type something unrelated mid-flow — treat it as a cancellation or ignore it?
Every one of these branches has to be decided and written.Cheap systems usually only build the happy path, leaving customers stuck everywhere else — which puts you right back to handling it manually.
At acceptance, the happy path will always pass. What you should be testing is the branches.
Part three: the slot engine (the most underestimated piece)
This decides which slots can be selected. It has to do at least three things:
- Schedules: who is available, when and where. And it needs to roll forward automatically from a weekly template, not be filled in by hand every week.
- Occupancy logic: how long does one booking consume? Different services run different lengths — do you need buffer time either side?
- Atomic slot locking: two customers tap the same slot at the same moment, and only one booking can go through.
That third point is the most common failure in booking systems. The fix is to lock the slot at the database layer first, and only write the booking for whoever wins — obvious enough in principle, but without deliberate handling both bookings go through and you're the one phoning a customer to apologise.
Testing it is simple: two phones, same slot, same moment.
Part four: reminder notifications
One the evening before, one two hours ahead. It looks like a small feature, but it needs a scheduling system: sweep the database every few minutes, find bookings that are due for a reminder, mark them sent after pushing — never twice, never missed.
The value here needs no explanation — your no-show rate goes straight to your revenue.
Worth flagging one pitfall: if the scheduler runs faster than the job finishes, the same booking gets processed twice and the customer receives two identical reminders. The fix is to mark the record "in progress" before starting work, not after finishing. You won't see this level of detail on a quote, but it's what determines the customer's experience.
Part five: rescheduling and cancellation
When a customer wants to change their time, is it two taps — or do they have to message you?
Self-service rescheduling and cancellation means: verify identity, release the original slot back to availability, write the new slot, notify you. Its value is getting you out of the front-desk role.
This is the feature most often cut from version one, and the one that hurts most once it's gone.
Part six: the admin backend
The side you look at: who's booked today, adjusting schedules, changing service prices, conversation history.
Without a backend, changing your opening hours means going back to a developer every time — and over the long run that maintenance bill costs more than building the backend properly up front.
Part seven: add-ons (pay only if you use them)
These aren't needed on every project:
| Item | When you need it |
|---|---|
| Online deposits | Businesses with high no-show rates or high ticket values. Payment gateway integration quoted separately per provider plan |
| Website integration | Customers also arrive via your website. Websites from NT$18,000; bundled work quoted on overall scope |
| Existing system integration | Data needs to flow into a CRM, POS or membership system.We need to see the other system before we can quote this |
| Natural language parsing | Customers who prefer to type "any openings Friday evening?" rather than tap buttons |
That last one deserves a note: the AI translates what the customer said into "probably this slot," butavailable slots are always queried from the database by code. Let the AI decide availability on its own and it will invent times that don't exist — leaving you to explain why the system said yes when the answer was no.
What you can cut from version one
If budget is tight, here's the order we'd cut in:
- Cut add-ons first— payments, integrations and AI parsing can all wait for version two
- Then cut multi-role support— if only one or two people take bookings, start with a single-person schedule
- Don't cut: atomic slot locking, reminder notifications, self-service cancellation, the admin backend
Those last four are the ones you'll regret saving on. The first two are the ones you can add later without a rebuild. The logic of this order is simple:only cut what won't require starting over later.
Don't forget the monthly running costs
Beyond the one-off build fee, there's the long-term:
- LINE Official Account monthly fee: paid directly to LINE. There's a free tier; you only need to upgrade if you exceed the outbound push quota. Replies to customer messages don't count against the push quota — only reminder pushes do
- Hosting: a few hundred to a few thousand NT dollars a year for a small system
- AI usage(if you build natural language parsing): billed by message volume. You should hard-code a ceiling into the system to avoid a runaway bill
All of these should be paid directly to the providers, with the accounts in your name.Letting the developer hold and bill them on your behalf is a common trap— the day you want to switch providers, you find the accounts and the data aren't yours.
Five questions to ask once you have a quote
- What happens when two people tap the same slot at once? (tests atomic locking)
- Can customers cancel and reschedule themselves? (tests part five)
- If I want to change my opening hours, do I have to come to you? (tests the backend)
- Whose scheduler runs the reminder pushes? (tests part four)
- Whose name is the LINE Official Account registered under? (tests ownership)
A quote that answers all five cleanly is worth paying a bit more for. Vague answers mean the cheap price has a cost attached.
Our LINE booking system starts at NT$45,000 and goes live in 3–4 weeks, with everything above included except the add-ons.
If you're not sure you need a custom build, start with Monthly SaaS or custom: six questions that settle it——For most people the answer is a monthly SaaS— which does our business no favours to say, but being straight about it wastes less of everyone's time.