Platform or custom build? A plain-English guide for tourism boards

Sooner or later every tourism board, council tourism team and regional organisation faces the same decision. The website is four or five years old, the brand has moved on, the content team spends its days fixing operator details, and someone on the committee asks whether this time you should build your own.

It is a fair question, and the usual way of answering it is wrong. Comparing a build quote with a subscription quote tells you what each option costs on day one. It tells you nothing about what you will pay over five years, or who carries the risk when something upstream changes. This guide sets out a fairer comparison, without pretending the answer is the same for everyone.

The two options, described honestly

A custom build. An agency designs and builds a one-off website for you, usually on a general-purpose content platform configured for tourism. You own the result. You also own everything that follows: hosting, security patching, upgrades to the underlying software, every integration, and the eventual decision to rebuild when the stack ages out. Each is a separate invoice.

A platform. You subscribe to a product that already does the destination-specific work: Operator content, search, maps, itineraries, hosting. The engine is shared with other destinations and maintained by the provider; your design sits on top. You don’t own the engine, and you accept the provider’s roadmap in exchange for not having to fund your own. The best platforms give you a bespoke design on that shared engine; the weakest give you a skin.

Both can produce a beautiful website. The difference is what happens in years two to five.

The five-year view

Put these rows in a spreadsheet for each option, and insist that whoever is quoting fills in every one, even with a range. A blank row is the cost nobody has priced yet.

1. Design and build, or implementation. The day-one number everyone compares. For a platform, this is usually onboarding and design, not engineering.
2. Hosting, security and performance. Content delivery, firewall and DDoS protection, monitoring, backups. On a custom build these are yours to arrange and renew. Ask where the data lives and what uptime is promised in writing.
3. Software maintenance. Patches, version upgrades, dependency updates and the testing that goes with them. This is the row custom builds most often under-price, because it is invisible until it is urgent.
4. Integrations and their own fees. Email marketing, analytics, accessibility tooling, translation, events. Some integrations carry their own third-party subscription costs under either model; the difference is who maintains the connection when a vendor changes its API.
5. Upstream changes you don’t control. ATDW is the obvious one. When its platform and API are upgraded, a custom build has to fund and coordinate its own migration, while a platform does it once for everyone. We cover what that involves in ATDW 2.0: what changes for your website. It will not be the last such change.
6. New capability. When you want a trip planner, a new map type or AI-readable content, what does it cost? On a custom build each is a project. On a platform, features built for one destination tend to arrive for all, so the question is whether the provider’s roadmap matches your needs.
7. Design refresh. Brands move on. Can the look be refreshed without rebuilding the site underneath? Price a year-three refresh under each model.
8. The rebuild. The row that decides most comparisons. A one-off website built today is, on the usual cycle, dated in about four years, and the organisation then funds a full rebuild. A platform subscription has no rebuild cycle to fund, because the engine is continuously maintained. A quote that assumes the site lasts forever is not a five-year quote.
9. Your own team’s time. Hours spent on manual operator updates, chasing the agency or working around the system, converted to a salary cost. Often larger than hosting.

Add the columns. Then ask which model treats the money as capital expenditure and which as operating expenditure. A subscription is operating expenditure, not a capital build, and for many councils and boards that is easier to fund and easier to defend.

Where a custom build wins

Be fair to the option you are leaning away from. A custom build is the right answer when:

• your requirements are unusual enough that no platform does the core job well;
• you have an in-house development capability with the time and appetite to own the stack;
• owning the code is a governance requirement, not a preference;
• your horizon is short, and the rebuild row doesn’t apply.

If none of those is true, the custom build is usually chosen for a feeling of control that the maintenance rows quietly take back.

Where a platform wins

A platform is the right answer when:

• the job your site does is the job every destination site does: inspire, inform, send visitors on to operators;
• predictability of cost matters to your board as much as the total;
• you want improvements to keep arriving without commissioning them;
• you prefer to have the risk work (hosting, security, upstream migrations) done by people who do it for many destinations at once.

One test: will we look like everyone else? Ask to see several of the provider’s sites side by side. If they share an engine but not a face, the design is bespoke. If you can tell at a glance they are related, it is a skin.

Questions to ask either way

Whichever way you lean, these belong in the tender or the brief.

• Accessibility. Is the site built to the current W3C standard, WCAG 2.2⁠ (opens in a new tab)? Be wary of “fully compliant” as a promise; ask for the approach, the testing and the tooling.
• Privacy. How does the provider meet the Australian Privacy Principles⁠ (opens in a new tab) under the Privacy Act 1988, and where is personal information stored?
• Security. Which recognised framework are their practices aligned with, such as the Australian Signals Directorate’s Essential Eight⁠ (opens in a new tab)? Ask whether the provider itself holds certifications or relies on those of its infrastructure providers.
• Reliability. What uptime is promised, where is the site hosted, and what happens to visitors if the origin server fails?
• Ownership and exit. Who owns the design? What do you get back if you leave, in what format, and how quickly?
• Launch. How long to go live after kickoff, with evidence from recent comparable projects?

Where Roam sits

We are one of the options, so we should say where we stand. Roam is a destination marketing platform: a bespoke theme for every client, built on a shared component library, with colour palette, header and navigation style and typography under your control. The model is one all-inclusive annual fee covering hosting, support, new features and patches, with no hidden fees; every new feature, patch and upgrade is included for as long as you’re with us; and when the look needs to move on, we refresh the theme on the same content and integrations, without re-platforming. Sites run on AWS and Cloudflare with a 99.9% uptime SLA and go live in 6-8 weeks. How pricing works sets out what is included, and the Visit Geelong & The Bellarine case study shows what the model looks like after a full year.

A fair comparison in one table

Fill it in with your own numbers before you compare quotes.

If you would like to work through the comparison with your destination’s numbers, book a demo and we will tailor it to you.