Custom booking system vs SaaS comes down to two tests: does your current tool fail a booking rule you need, and would building cost less than the subscription over three years? A custom build can become cheaper over time, but only if development and upkeep cost less than the subscription and workarounds it replaces. For ordinary appointments, SaaS may offer better value because the provider maintains the service, although your business still manages settings, staff permissions, integrations, booking rules and personal data duties.
Before paying for a replacement, confirm the problem your existing tool cannot solve. There are four main choices: keep it, move to another hosted or self-hosted product, commission only a missing integration or workflow, or build a complete system.
Is a custom booking system cheaper than SaaS in the long run?
Sometimes. SaaS spreads software costs into regular fees, while custom development needs a build budget and continuing maintenance. The deciding evidence is what you pay now, the cost of staff correcting bookings and a written quote for a like-for-like replacement.
If appointments already work correctly, replacing the subscription may cost more. If staff regularly repair conflicts, record the task and the time it takes. The guide to a booking management dashboard shows how to put those problems in front of staff each morning. First trial another setting or plan, then inspect the resulting calendar: a failed requirement is evidence for changing the system; an inconvenience that configuration fixes is not.
What each option costs over three years
Use your own invoices and quotations for a 36-month comparison. Square's UK Appointments pricing page, checked on 4 November 2026, lists Free for one location, Plus at £29 per month per location and Premium at £69 per month per location. Those base subscription prices exclude the rest of your operating costs; check the current terms, VAT treatment and any negotiated rate.
- SaaS over 36 months: monthly subscription multiplied by 36, plus any setup or onboarding fee, transaction or booking charges, extra paid seats and the cost of documented manual workarounds. Add paid integrations separately.
- Custom over 36 months: written build quote, plus monthly upkeep multiplied by 36, plus hosting, support, payment processing, messaging and third-party licences not already included. Add migration or integration work only where the build quote excludes it.
- Hosted tool plus custom integration: the SaaS total, plus an integration quote and its maintenance, minus the documented workaround cost it removes. Do not assume the workaround disappears until a test proves it.
Use an invoice for each existing charge and write down the assumption behind each future cost. If renewal prices change, calculate each year's subscription separately rather than using one rate throughout. Ask the suppliers to identify overlapping charges so hosting or support is not counted twice.
A custom quote should explicitly include or exclude discovery, design, integrations, data migration, training, accessibility testing, acceptance testing and deployment. It should say what happens if the business changes a requirement after approval. Without those boundaries, the SaaS and custom figures describe different products.
Keep a copy of the calculation with the quotes and invoices. For related reading, see the article about evaluating custom booking costs; do not treat a general example as proof of savings for your business.
Fees that grow with bookings: subscription tiers, per-booking fees, payment processing, extra staff seats
Suppliers charge differently. VisitScotland's guidance, updated on 2 July 2025, describes subscriptions and booking commissions for tourism businesses. Your own provider may use neither, so start with the contract and recent statements.
Subscription tiers and booking charges
Plan upgrades can be triggered by a required feature rather than booking volume. Square's UK plan comparison puts waitlists on Plus and resource management on Premium. Test the required feature on the appropriate plan before assuming it needs custom development.
Where a provider charges per booking, establish what counts as billable and what happens to a cancelled or refunded appointment. Reconcile a sample of charges to booking records before forecasting them. There is further reading about booking-volume charges, but use your own agreement for the figures.
Payment processing and staff seats
Taking payments remains a cost with either software choice. Square's UK price list shows 1.4% plus 25p for UK cards on its specified online purchase routes, not every appointment transaction. Identify the route you actually use and compare its charges on the provider's statement; see also the booking payment comparison.
Calendly's pricing page describes a paid seat as a user connecting calendars and hosting meetings, not a customer invited to one. Square lists unlimited staff calendars on its Appointments plans. Count bookable hosts under the relevant supplier definition, not every employee or customer, and check whether administrators also take a paid seat.
Who is responsible for personal data held by a SaaS booking tool?
Personal data is not property that your business owns outright. Your business will often be the controller because it decides why appointment details are used; the provider may be a processor for that work. The ICO explains those roles, which depend on the actual processing.
When a supplier acts as processor, the ICO requires a written agreement covering security, instructions and end-of-contract treatment. Its guidance is under review following the Data (Use and Access) Act. Review the contract with a qualified adviser if responsibilities are unclear.
Responsibility does not guarantee an export with every field you need. The ICO's portability guidance describes a defined right held by individuals, not a universal business right to a complete database copy. Verify contract export rights separately from legal obligations.
What you control: records and domain, and rights to code
These are separate questions. You need authorised access to booking records, control over domain registration and clear contractual rights to the software. Paying a developer or SaaS supplier does not settle all three.
Access to records
Agree who holds the database account and how a usable export is produced. Try the supported export while access is active, then match selected records against the original calendar. If essential fields are absent, leave the current account running while you arrange a supported route.
Your domain
The domain and booking service are separate. Nominet's registrant-facing Online Services guidance explains how .uk registrants can manage contact details, change registrars or transfer a domain. Confirm the registrant and renewal access before altering links; do not transfer the domain if only the booking destination needs changing.
Rights to source code
The Intellectual Property Office says copyright in commissioned work normally belongs to its creator unless ownership is agreed otherwise in writing. Specify source-code delivery, repository access, deployment notes, the database schema, modification rights and third-party licences in the contract. Have another authorised developer review whether the delivered materials permit a lawful handover, and resolve contractual gaps before final acceptance.
What does a custom booking system cost to run once built?
There is no standard monthly price. Budget for application hosting and database storage, security maintenance, backups, monitoring and incident support. Messaging services and changes to connected systems may create additional bills.
A maintenance quote should name response times, monitoring arrangements, backup frequency and recovery targets, including the amount of data that could be lost and how quickly service is meant to return. Ask who responds outside normal hours and which changes cost extra. Match the written terms to the budget rather than treating maintenance as an optional extra.
The NCSC advises small organisations to back up important information and know how to restore it. Test recovery in an isolated environment, first with synthetic records, then by restoring a real backup under restricted access to confirm it holds the bookings you need, deleting that copy afterwards. Verify that restored bookings can be opened; if recovery fails, keep the live system unchanged and fix the backup process before relying on it.
Rules a SaaS tool cannot express
A missing rule justifies investigation, not an immediate custom build. For example, Square documents resource management for Premium, which assigns rooms, chairs or equipment to services and reserves them during booking. A requirement for a worker and a room is therefore not, on its own, evidence that SaaS cannot do the job.
Write an expected result for each rule. Test a booking that needs a resource already occupied, a travel appointment that clashes with another journey, or a service requiring approval. Inspect the resulting calendar after a permitted and a conflicting attempt. Document failures, including the plan and settings used, before seeking a custom quote.
If the tool cannot express a required constraint, also investigate whether its supported integration features can bridge the gap. An existing system might take a provisional request while a separate workflow checks an eligibility rule before the booking is confirmed. Do not use an unsupported modification that compromises the provider's terms or leaves staff unable to recover bookings.
The middle option: keep SaaS and build only the missing connection
A complete replacement may be unnecessary when the booking calendar works but information must reach another system. Ask whether the provider supports connections to your CRM, accounting software, staff calendars, messaging service or payment provider, and whether its API permits the specific data flow. Check the supplier's documentation and access terms before pricing an integration.
Describe the trigger, the information transferred and what should happen if the destination is unavailable. Test one successful transfer and one failure, then verify that staff can identify and retry missed updates without creating duplicates. A small integration still needs a maintainer and a way to disable it while retaining the booking service.
Time to launch and delivery risk
A hosted tool can be configured without commissioning a complete application. A custom build starts with written requirements, then needs implementation and acceptance checks before customer appointments can depend on it. Either choice can be delayed if records or connected systems do not move as expected.
For custom work, require tests of simultaneous attempts to reserve the same slot and of a reservation hold that expires. Payment tests must cover a failed charge, one confirmed after a delay, and a payment that succeeds after the hold has expired and the slot has gone, which then needs a refund or another slot; Stripe's webhook guidance also describes event delivery and retries, so verify each event's signature and test repeated and out-of-order delivery without creating a second booking, because Stripe does not guarantee event order. Inspect the database and calendar after each case, not merely the on-screen message.
Include accessibility in acceptance testing, for a shortlisted SaaS tool as much as a custom build: the calendar must work with a keyboard, errors must be understandable and time limits must allow customers to complete the task. See booking-system accessibility considerations. Record defects and rerun the affected tests before going live; if critical cases fail, retain the existing booking route.
Use synthetic test data by default. Where real records are strictly necessary for a migration check, limit access, encrypt the copies, set a short retention period and securely delete them afterwards. Verify deletion and keep the live database untouched during test imports.
Lock-in and the exit route
SaaS depends on the provider's product terms and data-export capabilities. Custom software may depend on an individual maintainer or undocumented integrations. Government Digital Service guidance, written for the public sector, explains why managed services can save work while increasing switching difficulty.
A safe order for leaving a booking provider
Choose one system as the sole place that accepts new bookings at every stage. Before cutover, that is the old provider; after a verified switch, it is the new one. A parallel run means test bookings in the new system, never real bookings taken in both. Preserve the original account, website links and administrator access until the replacement is proven.
- Step 1: Confirm terms. Review cancellation conditions, retention rules and administrator access. Test the account login and record how to reach support. If access or export rights are unclear, stop before making any changes.
- Step 2: Export separately. Square documents a CSV of appointment history, but that does not establish an export of future bookings, customer profiles or payment records. Obtain and test those separately, comparing samples with the live records. If anything essential is absent, leave the old system running.
- Step 3: Reconcile payments. List saved cards, deposits, outstanding balances and refunds for each affected booking. Saved card details do not normally move in an appointment export; Stripe describes a separate, secure processor-to-processor migration where supported. For each booking, record the deposit already paid, how any remaining balance will be collected and which original payment account can issue a refund. Match these decisions to the provider statements before switching; never copy card details into a spreadsheet.
- Step 4: Test the new data. Import into an isolated environment and compare record counts, then check each future appointment's customer, staff, time, payment and cancellation state against the old system. Verify assigned staff and cancellations; reconcile changes made since the export. If mapping is wrong, discard the test import and repeat while the old system alone accepts bookings.
- Step 5: Switch every entry point. Arrange a controlled pause in new reservations, complete a final reconciliation and switch the website widget, Google Business Profile booking link, social buttons, email links, printed QR codes and directory listings. A booking link added by a third-party provider needs a removal request; Google gives providers 5 days to act on it, so check the profile until the old link has gone. Update API connections and connected calendars so they no longer create old-system bookings. Verify each entry point and one permitted new reservation. If critical checks fail, keep both channels closed, reconcile interim bookings, payments and cancellations into the old system, then reopen the old routes.
- Step 6: Close safely. Once every channel and outstanding payment is reconciled, keep a final export, confirm how refunds and disputes on old payments will be handled after closure, then cancel the old account and keep written confirmation. Under the ICO's processor-contract guidance, agree return or deletion of remaining personal data and copies, subject to lawful retention and backup arrangements. Obtain written confirmation of the outcome, then remove former staff and integration access.
When SaaS is the right answer
SaaS is sensible when it handles the required booking rules and you can accept its total cost. It removes the need to commission and maintain the booking application, but your business still manages its permissions and connections. Trial a normal reservation, a change and a cancellation, then inspect staff availability and test an export.
Plan for the supplier being unavailable as well as for price increases or a withdrawn feature. Keep a secure way to take provisional bookings and a process for entering them once service returns, without accepting the same slot twice. Review published changes and your fallback after an outage; if a core feature disappears, test alternatives before cancelling.
Five questions that settle it
Answer these from invoices, contracts and working demonstrations. If an answer is missing, keep the existing system active while you obtain it.
- 1. What does it cost? Add current fees and documented workaround time over 36 months. Reconcile the inputs with invoices before comparing a written quote.
- 2. Which booking rule fails? Record the expected result and test the relevant SaaS configuration. A repeatable failure is more useful than an assumption about missing features.
- 3. What must connect? List required CRM, accounting, calendar, messaging and payment connections. Confirm API support and test a sample transfer before choosing a complete replacement.
- 4. Who supports the alternative? Obtain quote inclusions and exclusions, with response and recovery commitments. Verify that another maintainer could lawfully take over if needed.
- 5. Can you leave safely? Prove that required records are exportable and the cutover has a rollback route. Do not cancel while channels or payments remain unresolved.
Choose the smallest change that solves the problem
If the present tool passes your booking tests, keep it; if one connection is missing, price that before replacing everything. You can send a project brief for your booking system to define a requirement before requesting quotes. Whichever way the custom booking system vs SaaS question falls, keep the old route live until the new one has passed its tests.