Global Fuel & Mobility Web Platform

Confidential client

Platform Lead contribution|Multi-region fuel and mobility web platform

TLDR

Frontend and platform architecture on a multi-region site across the US, UK and Ireland. Headless CMS, location pages at scale, external location and EV data, SEO, and a shared monorepo frontend layer.

Overview. The requirement was a maintainable web platform for regional content, hundreds of location pages, and operational data from external providers, without scattering provider logic across page templates.

ReactTypeScriptMonorepoHeadless CMSEdge hostingLocation data providerEV charging providerUnit testsComponent docsVisual reviewLintingStatic analysisGit hosting

My role

Frontend architecture and technical leadership on the web platform
Integration design for headless CMS and external location or EV data
Performance, caching, and SEO-oriented rendering choices
Shared packages and engineering standards in a monorepo
Collaboration with content, product, and platform teams on preview and delivery workflows

The challenge

Multiple regions with shared UI and region-specific content
300+ location and station pages that need to be crawlable and fast
Headless CMS for editorial content, separate from operational data
External location and EV charging providers behind clear boundaries
Preview and editorial workflows without leaking provider complexity into every page
Shared frontend architecture that supports additional regions

Conceptual architecture

Sanitised view

Traffic

Users / search engines

Platform

Vercel · Next.js · React UI · SSR · SEO · regionalisation · caching

Reusable frontend platform layer in Turborepo

Headless CMS

Structured content, media, preview

Location data provider

Business / location info

EV charging provider

Operational EV data

Delivery

Bitbucket → CI/CD → Vercel

Key architectural decisions

Problem, decision, rationale, and outcome for each architectural choice.

Server-side integration

Problem: Location and EV data comes from external systems. Browser-side provider calls would add latency, expose integration detail, and weaken SEO.
Decision: Keep provider-specific fetches on the server where possible, and shape page data before it reaches the UI.
Why: Simpler page components, crawlable content, and provider details contained in the server data layer.
Outcome: Location and EV data can power pages without putting integration complexity in the client bundle.

Caching external data

Problem: Location datasets and EV charger information are requested often. Uncached calls put pressure on third-party APIs and slow responses.
Decision: Cache selected external responses where safe. EV charger data used a short window of about 15 minutes. Location retrieval used cursor-friendly caching where appropriate.
Why: High page traffic should not force a full provider round-trip on every request.
Outcome: Fewer unnecessary external calls, better response times, and lower pressure on provider APIs.

Multi-region architecture

Problem: US, UK and Ireland need shared components with regional content and configuration, without three separate frontends.
Decision: Treat region as a first-class concern in routing, content selection, and configuration, while keeping shared UI and platform packages common.
Why: Separate apps per region would increase delivery cost and diverge standards.
Outcome: A shared frontend base that can support regional expansion without rebuilding the product per market.

Headless CMS separation

Problem: Editors need structured, localised content and preview. Application logic should not be mixed into CMS payloads.
Decision: Use a headless CMS for structured content, hierarchies, localisation, media, and preview or virtual staging. Keep rendering and integration logic in the platform layer.
Why: Editorial workflows and engineering boundaries need to stay separate on a content-heavy site.
Outcome: Content can evolve through models and delivery keys without each page defining its own CMS wiring.

Reusable frontend platform

Problem: Features need shared UI, utilities, and standards without duplicated components across packages.
Decision: Organise the frontend in a monorepo with shared packages for UI and utilities, and clear boundaries between platform code and feature code.
Why: Shared standards matter more as surface area grows.
Outcome: Shared patterns across the platform, with component docs, visual review, unit tests, linting and static analysis supporting the standard.

SEO-first rendering

Problem: Location and regional pages need to be discoverable. Client-only shells would hurt crawlability.
Decision: Use server rendering and server-side data fetching for content and location pages, with metadata and route structure treated as architecture.
Why: Search engines and users need real content in the first response.
Outcome: A rendering strategy suited to large location inventories and multi-region content.

External service boundaries

Problem: Location and EV providers each have their own shapes and operational concerns. Pages should not depend on provider-specific shapes directly.
Decision: Integrate behind frontend boundaries that map provider data into platform models, including migration work for EV data where needed.
Why: Provider changes should not require edits across every location template.
Outcome: Clearer ownership of integration risk, with the UI depending on stable page-facing contracts.

Preview and editorial workflow

Problem: Editors need to preview staged content safely. Preview behaviour and localisation hierarchies are easy to get wrong.
Decision: Support CMS preview or virtual staging through the platform, with attention to hierarchy, localisation, delivery keys, and content migration.
Why: Editors need to review against the real frontend before publish.
Outcome: Editorial review against the live frontend without shipping unreviewed content.

Impact

Supported a multi-region web presence without separate frontend codebases per market
Location-page architecture for 300+ stations with server-side data work
Reduced unnecessary external API pressure through targeted caching
Clearer frontend boundaries between CMS, location, and EV concerns
Shared monorepo patterns, tests, and visual review for consistent delivery
Analytics and feature flags used to observe and gate platform changes

Reflection

On a content-driven multi-region platform, the lasting work is data ownership, caching, rendering strategy, and integration boundaries, not only component structure.