"I'll have it built bespoke": what your own software really costs a motorhome site

We hear it at least once a month, usually at a show or on the phone, and it always sounds the same: "I do want a booking system, but I'm having one built by a lad I know. That way it's exactly how I want it, and at the end of the day it's mine." Put like that, it sounds like the most solid decision in the world: you pay once, you own the software, no subscription. It's the same logic you used when you bought the ride-on mower or resurfaced the hardstanding: you invest a serious sum and then the thing works for you for ten years.

The trouble is that software isn't tarmac. Tarmac you leave alone stays tarmac. Software you leave alone doesn't stand still: it gets worse. Rules change, the payment provider changes, the phones in your guests' hands change, the system it runs on changes. And that lovely system you paid £24,000 for in 2023 is now asking for more money just to keep doing what it did on day one.

In this article we put down in black and white the real numbers behind bespoke software for a motorhome site: what it costs in year one and what it costs by year five, why the price is the smaller problem, what happens the day the developer who wrote it stops answering the phone, and which questions to ask before you sign a quote. At the end you'll also find the other side of the coin: the cases (few, but they exist) where going bespoke makes perfect sense.

What bespoke software really costs (the quote is only the first instalment)

Let's start with the figure. UK agencies that publish indicative prices for 2026 are broadly in the same ballpark. One London agency puts a minimum viable product (a first version with three to five core features) at around £15,000 to £35,000, and a customer-facing web app at £30,000 to £75,000 (Softomate Solutions). Another UK developer gives a wider band of £25,000 to £150,000 for small and mid-sized projects (Dotsquares). These are agency figures, so treat them as orders of magnitude rather than quotes, but they give you the picture.

Where does a motorhome site sit? Higher than you'd think, because a booking system for a site isn't a diary. It has to handle availability in real time, take payments online through a certified payment provider, open a barrier, work out prices that change by season and length of stay, account for water and electric hook-up, keep the guest records the law asks for, feed your bookkeeping and, in Edinburgh and potentially soon parts of Wales, cope with a visitor levy. And it has to do it in several languages, because a good share of your guests come from the Netherlands, Germany and France. Every item is a module, and every module is a quote within the quote: that's how you end up somewhere between £15,000 and £45,000.

But the quote is only the first instalment, and here's the number almost nobody puts in front of you: a common rule of thumb puts the annual maintenance of bespoke software at 15% to 20% of the build cost (UK agency guides go as high as 25%). It isn't a penalty: it's what it costs to keep code alive. On a £50,000 system, that's £7,500 to £10,000 a year.

Let's run the numbers on a realistic example. A 30-pitch site, an initial quote of £24,000 for bookings, payments, barrier and guest records. Hosting, domain, certificate, backups and a data SIM: another £500 to £900 a year. Maintenance at 18%: roughly £4,300 a year. By year five you've spent close to £50,000, which over 60 months comes to more than £800 a month, for software that, as we'll see, is already out of date by then. Over the same period, an off-the-shelf campsite management platform costs a monthly subscription in the tens of pounds, or a small fee per booking: you pay more only when you're taking more.

The cost that never appears on a quote: your time

There's one item no agency writes into its proposal, because you don't pay it in pounds. When you commission bespoke software, you are the project manager. You're the one explaining what happens if a motorhome turns up at 11.40pm, how the system behaves if a card is declined after the barrier has already gone up, who gets a discount, what your staff can see and what they can't. And then you're the one reading the specification, testing the screens and pointing out that the calendar starts on Sunday instead of Monday.

Picture a site owner in the Lake District who commissions their system in the autumn. The winter disappears into Thursday-evening video calls. It's delivered in May, with the season already under way, and the first three weeks are spent discovering the bugs no desk test had caught: the receipt with the wrong date, the barrier that opens twice, the confirmation email that goes out in English to the German guests too. Perfectly normal bugs, every piece of software has them first time round: the difference is that the owner finds them, in high season, in front of real customers. Brand-new software is by definition software nobody has used yet; a platform already running at dozens of sites has taken those bugs on the chin at somebody else's expense.

After delivery, you're tied to one person

This is the point that weighs most, and the one people think about least when they sign.

In IT it's called vendor lock-in, and there's an even blunter way to measure it: the bus factor, meaning how many people would have to disappear for the project to grind to a halt. When your system was written by a single freelancer or a two-person studio, your bus factor is 1 or 2. Everything the software does, and above all why it does it that way, lives in the head of someone you haven't employed and don't control.

You'll recognise the practical consequences straight away:

• You don't set the timescales. The urgent change in August, for someone with ten other clients, becomes "we'll put it in the queue for September".
• You can't compare prices. Every change is a separate quote: you can't ask anyone else to do the same job, because nobody else knows that code.
• Owning the code isn't the same as having the code. Plenty of business owners assume that because they paid for it, the software is theirs. Then they discover they have no access to the repository, not one line of documentation, and no idea how the environment is rebuilt. On paper it's yours; in practice, without the person who wrote it, it's a sealed box.
• Switching supplier costs almost as much as starting again. A new developer has to understand someone else's work, often without documentation: faced with code like that, many simply suggest rewriting it. And you're back to the original quote.

Then there's the scenario nobody plans for: the talented lad who built your software gets a full-time job and stops freelancing. No malice, just normal life for a developer. But from that day on your site runs on something nobody in the world knows how to touch.

Software isn't a gate: it ages even if you leave it alone

The entrance gate, if you grease it once a year, still works after ten years. Software doesn't, because it doesn't live on its own: it sits on an operating system, a database, dozens of libraries written by other people, a payment service, maps, the system that sends the emails. All of those pieces get updated, change their rules and, every so often, simply get switched off. When that happens, your software stops working without you changing a single comma.

The numbers behind this are striking. In a McKinsey survey of chief information officers, 10% to 20% of the technology budget meant for new products was being diverted to resolving issues linked to technical debt, which they put at 20% to 40% of the value of their entire technology estate (McKinsey). Stripe's Developer Coefficient study found that developers spend more than 17 hours of a roughly 41-hour week, around 42% of their time, on maintenance issues such as debugging and refactoring rather than building new things (Stripe). If companies with their own IT departments have this problem, imagine a motorhome site with an outside supplier who comes when they can.

In your day-to-day it looks like this: the payment module stops being compatible with the new version of your provider's API and for a fortnight you can't take payments online; the booking page designed in 2023, on a 2026 phone, has its buttons in the wrong place and the motorhomer books elsewhere; the server needs upgrading because its version no longer gets security patches, and doing it means adapting half the software. Each one is a phone call, a quote and a wait.

UK rules move faster than your software

This is where it becomes specific to your sector, and it's why software for motorhome sites ages worse than almost any other kind.

Look at just the last couple of years:

• Making Tax Digital for Income Tax. Since 6 April 2026, sole traders and landlords with qualifying income from self-employment and property over £50,000 have had to keep digital records and send quarterly updates to HMRC using compatible software. The threshold drops to £30,000 from April 2027 and £20,000 from April 2028 (GOV.UK). If you run your site as a sole trader, your takings now have to flow into MTD-compatible software in a clean, digital form.
• Visitor levies. In Scotland, Edinburgh has charged a 5% visitor levy on stays from 24 July 2026, on the first five nights, and the council lists caravan and camp sites among the accommodation it covers (City of Edinburgh Council). In Wales, the Visitor Accommodation (Register and Levy) Act became law on 18 September 2025: the register of visitor accommodation providers opened on 1 October 2026, with a deadline of 31 March 2027, and councils that choose to adopt the levy can charge it from April 2027, at 75p per person per night for campsites (Welsh Government).
• Data protection. The Data (Use and Access) Act 2025 has been coming into force in stages: the main data protection changes from 5 February 2026 and, from 19 June 2026, a duty for every organisation to have a process for handling data protection complaints, acknowledging them within 30 days (Kennedys).

Three fronts in under two years, and the levies are being rolled out council by council, on different dates and with different rules. Now the real question: who has built them into your software? If your system is bespoke, there's only one answer: nobody, until you ring up, ask for a quote, approve it and wait for development and testing. Every new rule becomes a small project of its own, with its own cost and timescale. And in the meantime, in front of HMRC, the ICO or your council, you're the one who isn't compliant, not your developer.

With an off-the-shelf platform, on the other hand, keeping up with the rules is the day job of the people who supply it: the change reaches everyone at once and you only notice because a new field has appeared on the screen. If you want to see how much regulation runs through your system, we've pulled it together in Motorhome site regulations in the UK.

Payments and guest data: no room for improvising

Software for a motorhome site handles two very sensitive things: money and people's identity details.

On payments, the international security standard PCI DSS is now on version 4: since 31 March 2025 the requirements that had been deferred have also become mandatory, with no grace period. It isn't a one-off box to tick, it has to be maintained all year, and someone has to keep your payment integration up to date. With bespoke software, you pay that someone by the hour.

On data, you collect names and arrival dates for every guest aged 16 or over and, under the Immigration (Hotel Records) Order 1972, nationality and, for most foreign nationals, passport number and place of issue, records you have to keep for at least 12 months. Under UK GDPR and the Data Protection Act 2018, you are the data controller, not the person who wrote the software: if that database ends up where it shouldn't, the responsibility is yours. So you need to be able to answer very specific questions: where the data physically sits, who can access it, who runs the backups, who installs the security patches in August while your site is full, and who handles a data protection complaint within the new deadlines. And ask what happens if the system falls over at 9pm on August bank holiday with fifteen motorhomes queuing at the barrier: if the answer doesn't include a written service level and a number to call, that is your answer.

Go bespoke and you pay for every improvement. With a platform, two hundred others share the bill

This is the underlying economic difference, and it's counter-intuitive.

When the software is yours and yours alone, every improvement has a single backer: you. Want check-in with document capture? Quote. Confirmation emails in German? Quote. Last year's occupancy on the same chart as this year's? Quote. There's nobody to share the bill with, so most of those improvements never happen: they stay on the "when we've got time" list. Software bought to be "exactly how you want it" ends up being exactly how you wanted it in 2023.

With a sector platform, the cost of development is split between everyone who uses it. The feature a site owner in Cornwall asks for reaches you in Northumberland without you asking for anything; the bug found thanks to a site in Pembrokeshire protects yours; the change for a new rule is built once and rolled out to everyone. That's why platforms like CamperGate ship updates continuously (seasonal pricing, opening barriers from different manufacturers, digital check-in, occupancy statistics): features that in a bespoke project would cost thousands of pounds each.

Finally, there's a risk point worth saying plainly: you can cancel a subscription, but you can't cancel a £30,000 project you're not happy with. In the first case the supplier has to earn your business every month; in the second, they've already been paid.

When bespoke software genuinely makes sense

It would be unfair to say bespoke is always the wrong call. There are situations where it's the right one:

• You have a genuinely unique process that no platform can represent: not an aesthetic preference, but a way of working unlike anyone else's.
• You run a group of sites with volumes that justify an ongoing maintenance contract, not a call-out when something breaks.
• You need to integrate with proprietary systems you already have (a group ERP, a council platform) that don't offer standard connections.
• The software is your product, not your tool: you want to sell it to other site owners. But then you're not opening a motorhome site, you're opening a software company, and that's a different trade.

Outside those cases there's almost always a third way, and it's the most sensible one: a standard platform for 90% of the work and targeted customisation for the 10% that makes you different. Many sector platforms offer APIs to connect your website, your accounts or a particular piece of kit, without rebuilding from scratch the part that's the same for everyone. You pay for one bespoke piece instead of ten, and the rest keeps updating itself.

Questions to ask before you sign a quote

If bespoke still appeals, fine: do it, but with your eyes open. These questions, written into the contract, are what separate an investment from a problem.

1. Who owns the source code, and where is it kept? Insist on repository access in your name, not "managed" by the supplier.
2. Is technical documentation delivered with the software? Without it, handing over to another developer is close to impossible.
3. What does annual maintenance cost, in writing? If there's no figure, pencil in 15-20% of the quote yourself and see whether the numbers still add up.
4. Are regulatory changes included or extra? It's the most important question in a sector where something changes every few months (Making Tax Digital, visitor levies, data protection).
5. What's the response time in high season? You need a written commitment with hours and channels, not good intentions in August.
6. What technology is it built on, and how many UK developers know it? If it's a niche language, your bus factor is even lower than you think.
7. Where is guest data hosted, and who runs the backups? Ask when a restore was last tested, too.
8. What happens if you shut up shop tomorrow? The right answer involves a code escrow arrangement and an exit procedure, not "don't worry, it won't happen".

In practice: how to decide without regretting it

First, work out the five-year cost, not the one-year cost. Take the quote, add 15-20% a year for maintenance, hosting and services, plus an honest estimate for two or three regulatory changes. That's the number to compare against the alternatives: not the £24,000 on the day you sign, but the £45,000-50,000 over five years.

Second, try before you build. Almost every sector platform has a demo or a trial: before having software written from scratch, spend a season checking whether what you need already exists. In the vast majority of cases it does, and it costs you a trial instead of a year of development.

Third, choose what's reversible. It applies to software just as it does to hardware: if a decision can be undone in a month, it's a decision; if it can only be undone by writing off £30,000, it's a ball and chain. It's the same reasoning we used about kiosks in Payment kiosks on a motorhome site: why you don't need one.

In the end the truth is simple: you don't buy bespoke software, you marry it. You take on the supplier, their timescales, their prices and their fate, and you keep them for as long as the software lives. Anyone running a site already has plenty to maintain (the hardstanding, the hook-ups, the Elsan point, a whole season): the management system is the one thing you can afford to have someone else maintain. If you want to see how all this plays out in the site's accounts, the numbers are in Motorhome site profitability in 2026.