Adding a Booking System: Build or Integrate
Putting bookings on a website you already have is an add-on at EUR 350 to 750, with the quote confirming the scope. In a new build it costs EUR 1.500 to 3.500 when an existing scheduler is integrated into a step 03 business website, and EUR 3.500 to 7.500 when the booking engine is built for you as step 04. Start by integrating and let your own rules push you to building, never the other way around.
A fixed quote follows scoping either way. Below is the test we use to tell the two apart, written out so you can run it on your own business before you talk to anyone.
What integrating means
You use a product that already exists: a general scheduler such as Cal.com or Calendly, or the salon, practice or studio software your industry already runs on. Your site carries the service pages, the proof and the reasons to book, then hands over at the moment of booking, embedded in the page or on a subdomain styled to match.
You get availability, calendar sync, reminders, rescheduling and cancellation, maintained by somebody else. You give up control: the rules are theirs, the customer records live in their system, and the design goes only as far as their settings allow.
What building means
A built booking system is yours: your database, your availability rules, your admin screens, your emails. In a new build it is step 04 because it is an application, with a login, a dashboard, an API and records that must stay correct when two people click the same slot at once. It is worth the money when your rules cannot be expressed anywhere else, never because it will look nicer.
The test that decides it
Read these and count your yes answers.
- A booking reserves something other than a person's time: a room, a chair, a machine that several services share.
- Availability depends on a combination: this treatment, with this practitioner, in this room, and only after that other appointment.
- You take a deposit or the full amount at the moment of booking. That alone means step 04 in a new build, or the payments add-on at EUR 600 to 1.500 on an existing site.
- Customers buy credits, class packs or memberships that bookings draw down.
- Booking data has to live in your own database, because you report on it or another system you run needs to read it.
- Your staff need to work inside your own admin rather than logging into a second product all day.
No yes answers: integrate, and spend the difference on the pages that convince people to book. Yes to the deposit question: step 04 in a new build, or the payments add-on on an existing site. Yes across resources, rules and data together: build it as step 04, or as step 05 from EUR 7.500 if discovery shows it needs accounts, billing and an admin of its own.
Side by side
| What you compare | Scheduler integrated into your site | Booking engine built for you |
|---|---|---|
| Cost | Part of a step 03 business website, EUR 1.500 to 3.500 | Step 04, EUR 3.500 to 7.500 |
| Time to live | 3 to 6 weeks | 6 to 12 weeks |
| Ongoing | Their subscription, billed by them, plus care at EUR 100 to 300 per month for the site | Care at EUR 100 to 300 per month, with no third party subscription for the booking itself |
| Where the data lives | In their system. Check the export before you commit | In your database, which you own |
| Design control | Their settings, inside your page | Yours, down to the last screen |
| Rules you can express | Whatever the product already supports | Whatever you can describe in a sentence |
| When it breaks | Their support queue, on their timetable | Ours, under care |
What moves the number
- Staff. One person with one calendar is simple. Several people whose availability rules differ is not.
- Shared resources. Once two services compete for one room or one machine, the system has to reason about more than a diary.
- Series. A course of appointments, or a weekly slot, booked in one action.
- Reminders. Email is part of the build. SMS brings a provider account and a cost per message that is theirs, not ours.
- Locations and languages. Two sites, or Dutch and English side by side, widen both design and content work.
- Syncing. Writing into a calendar or practice system you already use adds scope.
Process and timeline
- Scoping. We write your availability rules down in plain sentences. If they fit in a paragraph, an integration will hold them. If they need a page and a diagram, it will not.
- Design and content. Service pages first, booking second. People book once they are convinced.
- Build. An integrated scheduler is configured, styled and tested inside the site. A built engine is developed against your real rules, then handed to your staff to try to break.
- Launch. We watch the first real bookings arrive with you, because that is when the exceptions nobody mentioned show up.
- Care, EUR 100 to 300 per month: updates, monitoring, backups and small fixes. Not a redesign, not new features.
Integrated inside a business website runs 3 to 6 weeks. A built engine runs 6 to 12 weeks. The part that waits on you is the rule list and access to your calendar, so the sooner those arrive, the sooner everything else moves.
When to spend less
If one person keeps one calendar and answers the phone, you do not need a booking system. You need to be easy to reach and easy to believe. A step 01 landing page at EUR 600 to 900 with your hours, location, prices and a form is a legitimate answer.
If you want online booking and your rules are ordinary, a scheduler on its own page, linked from a step 02 mini-site at EUR 900 to 1.500, takes bookings from the day it goes live and can be replaced later without rebuilding anything around it.
If you already pay for scheduling software that works, keep it. Paying anyone to rebuild something that already runs is a bad trade, and we will say so in the scoping call rather than quote for it. The full price list is on the packages page.
Ownership, data and hosting
You own the code, the repository and the database we build. With an integrated scheduler the customer records sit inside that product, so check its export format before you commit, because that is the part that is painful to undo. Booking data is personal data, so keep a processor agreement with whichever scheduler you pick. Hosting is agreed per project.
Questions buyers ask
Can we start with an integration and build later?
Yes, and it is a sensible order. The service pages, the content and the search work carry over untouched, and only the booking step is replaced. We build the booking link as a single component so that swap stays a small job instead of a rebuild.
Will an embedded scheduler look like the rest of the site?
Close, not identical. Colour and font may be settings you can change, but the layout of the booking steps is set by the product, and your own styling cannot reach inside its frame. If that detail matters more to you than the budget difference, it is a real argument for building.
What about deposits and no-shows?
A deposit is a payment. Some schedulers collect deposits inside their own product, which keeps that side out of your build. Taking payments on your own site is step 04 at EUR 3.500 to 7.500 on a new build, or the payments add-on at EUR 600 to 1.500 on a site you already have. Either way, the quote confirms the scope.
Does online booking help our search rankings?
Not by itself. Rankings come from pages that answer what somebody typed, plus the technical hygiene underneath them. If search is the goal, the SEO foundation is a one-off at EUR 450 to 750, and continuing work is SEO growth at EUR 500 to 800 per month. We build fast, indexable service pages with Next.js.
Describe your availability rules in your own words and we will tell you which of the two you need, with the number attached. Get in touch.
Building something?
JP Studio designs and builds websites, storefronts and product interfaces.