Ask whether you can build your own booking system and the answer is almost always "yes, if you have the skills". That answer is true and useless for making a decision. A self-built booking system does not fall over while you are building it. It falls over after it is finished and starting to work.
This article separates the three routes people mean by "building your own", then puts a published number against the point where each one stops. After that: when building really is the faster path, and the smallest sensible setup if you decide to hand it over.
Contents
If you take bookings on your own or in a small team, the solo and small teams resource hub collects the rest of this ground.
The conversation stops at "can it be built"
Ask a public Q&A board whether you can build a booking system from scratch and which languages you need, and you get back a list of languages. That is permission to start, not an answer about whether you can keep it running. The problems show up months after launch.
Three things actually decide it: which route you build on, what ceiling that route has, and whether anyone other than you can fix it when the ceiling is reached. In that order.
There are three routes, not one
"Building your own" covers three different projects with different failure points. Comparing costs before naming the route produces numbers that do not line up.
| Route | What you build | Time to first version | Where it stops |
|---|---|---|---|
| 1. Form + spreadsheet + script | Intake and automatic replies | A few days | Execution and email quotas; simultaneous requests |
| 2. Booking feature of a site builder | A booking page | A few hours | Whatever the vendor built; no extra fields or payments |
| 3. From scratch | Everything | Weeks and up | Security and maintenance stay with you permanently |
Route 1 is the common one. There is already a spreadsheet holding the bookings, and adding automatic intake and replies on top of it is a natural next step, so the numbers below assume it. Route 2 is building without building; route 3 is building where everything comes back to you.
The free-tier limits are published
Google Apps Script, which route 1 runs on, has quotas published by Google. They are set by account type and have nothing to do with how well the thing is written.
| Quota | Consumer Google account | Google Workspace |
|---|---|---|
| Script runtime | 6 min / execution | 6 min / execution |
| Triggers total runtime | 90 min / day | 6 hr / day |
| Email recipients per day | 100 / day | 1,500 / day |
(Source: Google, "Quotas for Google Services", Apps Script documentation, as of August 2026, applying to Google Apps Script.)
These start to bite as bookings grow. Twenty bookings a day with a confirmation and a next-day reminder is forty messages. Add change and cancellation notices, resends for anything that bounced, and your own copies, and 100 is within reach. The failure arrives with growth: nothing in the code changed, and it stops working anyway.
There is not much room to route around it either. Splitting long jobs into five-minute pieces chained by triggers is a documented workaround, but the time still counts toward the same daily total. What you can reduce is how much you send and run; the ceiling itself does not move.
The work that remains after launch
A booking system holds names, phone numbers, email addresses and the times people will be somewhere. That is a list of who is where and when, and a leak matters more than it would from a contact form. Publish it yourself and defending it is also yours.
Japan's Information-technology Promotion Agency (IPA) publishes "How to Secure Your Website" for site developers and operators, listing eleven vulnerability classes and their countermeasures — SQL injection, session management flaws, cross-site scripting, CSRF, and missing access or authorisation control among them (source: IPA, "How to Secure Your Website", 7th revision, last updated 31 March 2021, addressed to website developers and operators).
On route 3 that list is your task list. Even on routes 1 and 2, the last item — missing authorisation control, where one customer's confirmation page exposes another's booking — is easy to introduce through how the URLs are built. And the only person who will ever review it is the person who wrote it, for as long as it runs.
Putting the costs side by side
Building is called free, and three costs appear once you write them down. Only one of them has a price tag; the other two are paid in hours.
- Somewhere to put it: route 3 needs hosting. Xserver's Standard plan is ¥693/month (campaign price on a 36-month term; ¥990 normally, tax included, as of August 2026 — source: Xserver pricing). Routes 1 and 2 avoid this
- Time to build: days on route 1, weeks on route 3. Multiply by your own hourly rate
- Time to fix: platform changes and errors arrive unannounced. This is the one line whose total cannot be forecast
Say route 1 takes twenty hours up front and two hours a month afterwards. At ¥3,000 an hour that is ¥60,000 to build and ¥6,000 a month to keep. Whether that beats a subscription depends on what you price your own hour at, not on how many bookings you take.
When building really is faster
Off-the-shelf is not automatically right. If any of these describes you, building is the shorter path.
- Internal only, never public: booking rooms or equipment for colleagues works fine on a spreadsheet and a script
- It has to connect to an existing core system: linking stock or membership records is beyond what settings screens reach
- Someone owns it as part of their job: with a named owner and a handover, quotas can be designed around
If none of the three applies and route 1 still appeals, the motive is usually not wanting a monthly bill. In that case, price your own hour before deciding and the decision gets much shorter.
The smallest setup worth handing over
Handing it over does not mean moving everything at once. Move only the part that hits the ceiling: showing availability, confirming the booking, and sending confirmations and reminders. With those outside, the rest of your reporting can stay in the spreadsheet.
There is not much to check when choosing:
- Is there a cap on bookings? A monthly booking limit means migrating again once you grow
- Does the calendar sync both ways? Whether events booked elsewhere block the time is the whole double-booking question
- Can you set the intake fields? A fixed set sends you back to email for the rest
- Is pricing independent of volume? Per-booking fees close the gap with building it yourself as you grow
Below, as one example of a tool that meets those four points, we look at SailLab.
SailLab
SailLab is a Japanese booking system that takes on published availability, intake and notification email — which is precisely the part of a self-build that hits its ceiling first.
- No cap on bookings: monthly bookings are unlimited even on the Free plan, so the 100-a-day wall does not apply
- Confirmations and reminders are standard: no sending infrastructure of your own, with configurable timing before or after the appointment
- Two-way sync with Google and Outlook: anything booked outside SailLab blocks the time automatically
- You build the intake fields: eleven field types, reorderable, each with required/optional and validation
- Vulnerability work leaves your desk: encryption in transit, role separation and audit logging sit with the provider
| Plan | Monthly (annual billing, ex-tax) | What matters here |
|---|---|---|
| Free | ¥0 | One booking page, unlimited bookings, Google / Outlook sync, confirmation and reminder emails |
| Light | ¥800 | Unlimited pages, custom URL, SailLab branding removed, editable email templates |
| Standard | ¥1,200 | Menu-style bookings, upfront payment, round robin, booking analytics |
What route 1 was going to cover usually fits inside the Free plan (as of August 2026); see pricing for the details, and freelancers and sole traders for how a one-person setup uses it.
One limit worth knowing before you start: there is no widget to embed the booking screen inside your own site. If putting it directly on your page is non-negotiable, route 2 or 3 fits the requirement better, and it is worth settling that before writing any code.
Settling it in ten minutes
Build or buy comes down to five answers.
- How many notification emails go out on a busy day? (Near 100 and route 1 will not hold)
- Can anyone but you fix it? (If not, a day of downtime is a day of lost bookings)
- Will the data hold names and phone numbers? (If so, defending it is your job)
- What is an hour of your time worth? (Convert the first twenty hours before comparing)
- Is putting the booking screen inside your own site non-negotiable? (If it is, you are on route 2 or 3)
Two red lights on the first two questions and the conclusion is already in before you start. If only the fifth one catches, route 2 is the shortest path.
If you are already taking bookings on Google Forms, see where Google Forms stops working as a booking system. If the diary stays in a spreadsheet, booking management in Excel covers doing that properly, and what a booking form should contain covers the intake side.
SailLab's Free plan needs no credit card — create an account to try it.
Ken Morimoto ／ SailLab Editorial
Writes for SailLab Editorial on running bookings and scheduling with the tools already on hand — Google Calendar, Google Forms, Excel, Teams — and where each one stops.
Automate your booking flow with SailLab
Calendar sync, automatic reminders, and prepaid bookings — all in one booking page. The Free plan takes 3 minutes to set up, no credit card required.