Vodafone

Vodafone is a Telecomms provider headquarted in the UK with a direct presence in 15 countries. With over 300 million customers worldwide, their core UK digital capabilities started a transformation in early 2017. I was incredibly fortunate to be one of the first people engaged at the beginning of this journey and led the front-end of the transformation.

What shipped

vodafone.co.uk
- Self-published server-side rendering solution (react-ssr)
- Reusable, themeable React component library forming their first true design system
- Stateful journey composition APIs
- An architectural journey from monolith to micro sites to micro front-ends
- A node.js middleware back-end for front-end layer

Impact

Faster delivery cadence: 10hr+ overnight releases per sprint → 100+ releases a day in minutes
Performance & SEO lift: SSR + caching improved CWV pass rate and organic visibility
Reusable design system: component library adopted by 8 teams, driving UI consistency and faster build times.
Quality gates: CI with unit/E2E/visual checks caught regressions pre-prod.
Developer productivity: Node BFF reduced client complexity.
Scalable architecture: monolith → micro-sites → micro front-ends, enabling parallel workstreams and safer experience updates.

My role & scope

Principal Front-end Developer that introduced the React/Node stack at the beginning of the digital transformation in a team of 3-4 engineers, before scaling to 8+ teams and 50+ engineers
Led on front-end architecture, taking it from monolith, to micro-sites (a react web app per domain), to micro front-ends (individual consumable federated modules)
Designed and implemented the node.js proxy middleware servicing millions of vodafone.co.uk API requests
Sole creator of server-side rendering library and babel plugin for SEO complaint pages, before well-known frameworks were common place
Setup quality automation strategy, educating teams on pillars of testing, with a focus on unit tests, end-to-end tests with Cypress, and visual regression with Applitools
Founder of first React web component library, documentation and theming system, servicing vodafone.co.uk and related digital products

Key decisions & trade-offs

Build our own SSR (react-ssr) vs adopt early frameworks
- Trade-off: full control and SEO/perf wins vs maintenance burden
- Why: Next et al. weren’t mature/available for our constraints; we needed predictable SSR and SEO guarantees immediately.
Incremental migration (monolith → micro-sites → micro FEs) vs big-bang
- Trade-off: some duplication/overhead vs continuous value delivery and lower risk.
- Continuous value delivery paid off and allowed Vodafone to mature a reliable digital capability
Node BFF layer vs direct client→API
- Trade-off: extra hop vs cleaner contracts, server-side composition, and cache/control at the edge
- BFF layer cleansed contracts initially (due to legacy tech debt in APIs) but we gradually evolved it to a thin proxy layer
Design system with tokens & theming vs ad-hoc components
- Trade-off: upfront investment vs long-term velocity, consistency, and multi-brand reuse.
- We spun up a dedicated team (that I led) to spearhead the first library and reduce time to realize benefits
Module Federation micro FEs vs single SPA
- Trade-off: runtime complexity vs true team autonomy and independent deploys.
- We frequently found changes to shared global components, like the header, meant 5+ teams needed to co-ordinate releases to avoid major inconsistencies in journeys. Module federation solves this - we just use it sparingly.
Stateful journey composition APIs vs page-level orchestration
- Trade-off: centralised logic to maintain vs simpler client code, consistent flows, and observability.
- We found our front-end code became brittle with orchestration and business logic, centralising this in the service layer was a natural evolution