Dori Media

Engineering note

Build versus buy: when an off-the-shelf booking system stops being enough

When off-the-shelf booking software is the right call, when it has genuinely stopped being enough, and how to weigh building your own without it ballooning.

Custom software Booking systems NZ business Laravel Stripe
About 11 min read Published 1 November 2025

Founder, Dori Media · Christchurch · Laravel & Stripe since 2011

On this page

The booking tool does eighty percent of what you need. The twenty percent it cannot do happens to be the twenty percent that is actually your business.

Or you are on a tool that mostly works, but the pile of bolt-ons and the spreadsheet beside it have grown until they are half the operation. Calendars in the SaaS. Pricing in a sheet. Bonds handled in email. Reminders in someone's head.

That is usually when this question lands. Should we keep paying for this thing and working around it, or should we build our own?

Most people who ask me that want permission to build. The honest answer, most of the time, is buy.

The honest default is buy

Off-the-shelf booking software is cheap, fast, and maintained by someone else who has spent years hardening it. Calendars, reminders, payment handling, customer notifications. That is largely solved. You can be live in days, not months.

For a standard process at sensible volume, renting the tool is almost always the right call. I will say that on a first call when it is true. You do not need me. You need a product that fits well enough and a decision to stop shopping for the perfect one.

Building your own booking system out of pride, when a generic tool would do, is an expensive way to relearn problems other people already fixed.

The signs off-the-shelf has genuinely stopped being enough

These are the signals where buy-first stops being the right default. I have lived this from the operator side, not just as a developer quoting someone else's pain.

Your pricing does not fit their model. Seasonal rates. Per-kilometre charges. Multi-day rules. Bonds and deposits held and released on conditions the tool was not built for. Dynamic pricing that changes with fleet or season. You are either hacking workarounds inside the product or doing the real pricing by hand outside it.

You run more than one brand on one operation, and the tool assumes one. Jimny Rentals, Dream Drives, Wilberforce Offroad. Same infrastructure, different customer-facing brands, different rules in places. An off-the-shelf rental platform often wants one business, one price list, one website. You end up with duplicate accounts, duplicate fees, or a Frankenstein setup nobody fully understands.

The tool owns your customer data and you cannot get at it. Exports are awkward. The API is thin or missing the fields you need. You cannot wire bookings into the rest of your stack without manual re-typing. Your business runs on the data. Renting a black box for that gets old.

The fees scale badly. Per booking or per seat looks fine at low volume. It quietly becomes a tax as you grow. At some point you are paying heavily for software that still does not fit, plus paying staff to work around what it will not do.

The workflow that is your edge is the exact thing the tool will not do. Not a cosmetic annoyance. The actual way you take bookings, allocate fleet, handle bonds, or run multi-brand ops. If that lives outside the product, you are not really on one system. You are on the product plus an unofficial second system made of sheets and process.

That was my situation with vehicle rental. We ran on VEVS, an off-the-shelf rental platform. It was fine until it was not. The pricing model did not match how we actually hired cars. The multi-brand setup did not match how the businesses were structured. The workarounds accumulated. Leaving was not a mood. It was maths and fit.

The signs you should stay bought

Annoyance is not a business case.

If the tool does the job and you are irritated by small things, keep it. Change process. Train people. Live with a button in the wrong place. That is cheaper than a rebuild.

Low volume, the maths does not work. If you take ten bookings a month, a $150/month SaaS plus a bit of grumbling beats a $30,000 build every time.

Standard process, generic tool. Appointments, classes, simple hourly hire with flat pricing. A mainstream booking product will handle that better than a fresh custom build will, for years.

Do not rebuild calendars and reminders out of pride. That is solved. The SaaS does it better than version one of your app will. If your only complaint is "I wish the emails looked nicer," you are still bought.

I have told operators to stay on what they had. That is a good outcome. It only works if I mean it.

The real cost comparison people miss

Neither option is free.

Off-the-shelf has subscription fees, per-booking charges, payment processing, and the hidden labour of workarounds. The spreadsheet beside the booking tool. The admin who fixes pricing by hand. The duplicate data entry into Xero. That time is money even if it is not on a software invoice.

Custom has the build, hosting, and maintenance. It also has the upside that you stop renting the core of your operation forever.

The honest comparison is total cost over a few years, not the sticker price on the SaaS homepage. When SaaS fees plus workaround labour pass what a custom build and its upkeep would cost, and the fit genuinely matters to how you make money, build starts to make sense.

For what a build actually costs in NZ bands, see what custom software actually costs in NZ. This article is the "should you?" The cost piece is the "what would you pay?"

The middle path most people miss

It is not all or nothing.

Keep the commodity bits. Payments through Stripe. Standard calendar flows where they are truly standard. Build only the part that is yours: the pricing engine, the fleet rules, the multi-brand layer, the bit the SaaS will never bend to.

Or start bought and build later once you know exactly where the tool fails you. Run on VEVS or whatever fits for now. Document the gaps. Build the twenty percent that is your business. Do not rebuild the eighty percent that is already solved.

That phased thinking is the same move as when to replace a spreadsheet with custom software: one painful workflow first, not the whole company at once.

What it looks like when you build it right

We replaced the off-the-shelf rental platform with Glovebox. Same operator reality underneath: fleet, bookings, bonds, payments, pricing that reflects how hire actually works in NZ.

The booking flow fits our pricing instead of our pricing bending to fit the tool. We own the customer data. It talks to the rest of the stack. It runs more than one brand on shared infrastructure where we need it to. We stopped paying per booking for software that still required a spreadsheet beside it.

Before: rental ops split between a generic platform, manual pricing fixes, and workarounds nobody loved. After: one system built for how those businesses actually run. Still in production. Still growing.

On the other end of the timeline, I have built and maintained custom booking systems for Targa since 2011. Event transport and logistics, high-pressure dates, software that has to stay up when the event does. That is the "build because the workflow is genuinely yours" case from day one. Not every business looks like that. When it does, off-the-shelf rarely fits.

How to make the call without it ballooning

Write down what off-the-shelf genuinely cannot do. Not what annoys you. What breaks revenue, trust, or ops if it stays wrong.

Cost that against the SaaS plus workaround total over two or three years. Be honest about the labour. Include the key-person risk if only one person knows how the workarounds work.

If build is still the answer, scope the smallest part that fixes the biggest pain. Not "replace everything." Not version one of the perfect platform. The pricing layer. The multi-brand split. The bond workflow. Get that working. Use it. Expand.

Once you are in build territory, the money question is the cost article. The spreadsheet piece is the earlier fork if you are still deciding whether software is the fix at all.

The web apps and platforms work I do is for operators who have crossed that line.

How I work

First, a free chat. I want to hear what you are on now, what the tool will not do, and what "enough" would look like.

If we are heading toward a build, a written scope: what I would build, what it costs, and what it costs to stay where you are. Keep the tool you have got is a real outcome. So is buy a different SaaS. So is build one piece, not the whole stack.

If you want a straight conversation, get in touch. No hard sell. Just working out whether you should stay bought, buy something else, or build the part that is actually yours.

This note sits under Web apps & platforms. See also all journal writing.

Building something similar?

Want to talk it through?

Booking systems, internal tools, multi-tenant platforms. I build and run them from Christchurch, and I will tell you honestly if you should stay on what you have got.