When headless builds are worth it for maritime brands

“Headless” gets pitched on every maritime redesign brief above £40K. Most of those pitches are wrong, in the sense that a headless build is the wrong tool for the job and the agency is selling it because it’s what they like building. A small share of those pitches are right, in the sense that the project genuinely benefits from a headless architecture.

Knowing the difference saves real money and ships better sites.

What headless actually buys you

A headless architecture decouples the content store (a CMS like Sanity, Storyblok, Contentful, Strapi or Hygraph) from the front end (typically Astro, Next.js, Nuxt or SvelteKit). The advantages are real and specific:

Performance. A static-rendered or edge-rendered site on a modern stack can be twice as fast as a well-tuned WordPress site, particularly on high-latency, satellite or weak mobile connections. For maritime audiences, this is meaningful.

Composable content. Content modelled once can be reused across web, mobile app, intranet, partner portal and API consumers. If you have multiple consumers of the same content, that reuse is genuinely valuable.

Front-end flexibility. The team can do things on the front end that fight WordPress: complex interactive product configurators, real-time data visualisations, custom search experiences powered by Algolia or Typesense, sophisticated filtering on large structured datasets.

Developer experience. Modern stacks ship with type safety, component-based architecture, first-class testing and clean Git workflows. Engineering teams who maintain headless stacks generally prefer them to WordPress.

What headless costs you

Developer dependency. Every change beyond what the CMS schema supports needs developer time. A “let’s add a new page type” request that takes 30 minutes in WordPress can take a sprint in headless if it requires schema changes, front-end components, preview configuration and deployment.

Editor friction. A non-technical marketing manager who’s used to WordPress-style ad-hoc page editing will find a structured CMS more constraining. The CMS isn’t worse, it’s stricter. Some editors love this; some never adapt.

Ecosystem gaps. WordPress plugin ecosystem is huge and battle-tested. Need WPML for multilingual? It works. Need ACF for custom fields? It works. Need a HubSpot embed, Salesforce integration, Cloudflare Turnstile? All trivially supported. Headless stacks often require custom integration code where WordPress has a one-click plugin.

Higher build cost. A headless build is usually 30 to 60% more expensive than the WordPress equivalent for the same scope. The ongoing cost can be lower if traffic and content are stable, but the up-front investment is real.

The conditions that actually justify headless

Not “we want a fast site” or “the developers prefer it”. Specific conditions, any one of which can independently justify the choice:

1. Multi-channel content reuse

You publish to web, a mobile app, a customer portal, a partner extranet and an API for data consumers. All of them need the same content models. A headless CMS is the correct architecture; WordPress is technically possible but awkward.

A real example: a marine equipment manufacturer with a public product catalogue, a dealer-only portal with extended technical data and a service-app that pulls product specifications. One Sanity content model serves all three. WordPress would require three content stores or aggressive REST API gymnastics.

2. Performance is contractual

If you have an SLA with a major client, a regulatory requirement (rare, but starting to appear in port community contexts) or a hard performance budget tied to a specific outcome (LCP under 1s on satellite), a headless build is the only way to hit the numbers reliably. WordPress can be very fast, but consistently sub-1s LCP at scale is hard.

3. Complex structured data on the front end

Filterable fleet pages with 800 vessels and 30 attributes per vessel. Live AIS data overlays. Real-time bunker price displays. Interactive port arrival schedules with drilldowns. WordPress can do these with custom development, but a Next.js or Astro front end with a typed data layer is genuinely cleaner.

4. Engineering team capacity

You have or will have ongoing in-house or retained engineering. A solo marketing manager with no developer support should not run a headless site. A digital team with a developer or two and a design lead can run one well.

When headless is wrong

A 60-page maritime corporate brochure site for a ship manager with one marketing person, no integrations beyond HubSpot, no fleet page beyond a static list, no multi-channel publishing requirement and no performance contract. WordPress every time. The headless build will cost more, ship later, be harder to update and deliver no commercial advantage.

We’ve inherited too many of these. The original agency built headless because they wanted to. Three years in, the marketing team has stopped publishing because every change needs a Jira ticket and a PR review.

Three questions before you commit

Three questions:

1. Do you have ongoing developer capacity (in-house or retained)? No, headless is wrong.
2. Is the same content consumed by more than one front end? No, headless is unjustified by reuse.
3. Do you have a performance, integration or interactivity requirement that WordPress genuinely can’t meet? No, you don’t need headless.

Three nos and you’re choosing the wrong tool. Three yeses and headless is the right answer.

The honest version: WordPress on a hand-coded theme handles 80% of maritime corporate sites better and cheaper. Headless wins on the remaining 20%, and on those it wins decisively.