Building a Web Platform for 80 Sites

Context

I joined Elanco’s global digital team as a full-stack developer on my industrial placement (2019–20). When it ended, COVID and Elanco’s fully remote working policy meant I could carry on at almost a full-time position through my final year (2020–21), essentially from my university dorm room, balancing it alongside my studies, my dissertation and whatever social life and hobbies COVID allowed (not many). That extra year of real experience put me in a good position straight after graduating: I went into my next role without needing a junior position first.

The web estate was around 80 active sites, built at different times by different teams in different ways. Every new site was a fresh set of decisions, and every shared change had to be made 80 times.

Problem

There was no paved road. Teams picked their own framework versions, built their own components, wired up their own deployments and used the CMS in their own way. That made every site expensive to build, harder to maintain, and nearly impossible to change all at once.

What I did

1. Set the standards. I wrote web development standards for the team: which React versions to use (and where Preact made sense for lighter sites), and which frameworks to build on, weighing Next.js against Gatsby for content-heavy sites.
2. Turned the standards into a starting point. A standards document is easy to ignore, so I built a Web Accelerator: a boilerplate with those decisions already made.
3. Made it self-service. I integrated the accelerator with the company’s self-service portal, so a team could provision a new project themselves rather than waiting on us.
4. Built the road to production. I set up Azure Front Door and the deployment architecture, so every accelerator site shipped the same way.
5. Documented everything, endlessly. The approach only scaled if people who’d never met me could use it, so the docs were part of the product.
6. Shared the components. To speed things up further, I adopted Storybook to hold Elanco’s reusable components (a shared component library), then applied them across the 80 sites.
7. Consolidated. With shared structure in place, we integrated and consolidated the estate into three main company sites: business, products and tech.
8. Migrated the CMS, then led it. I worked on the migration to a headless CMS, including content and media migrations in TypeScript and GraphQL, then stayed on the CMS project as lead developer to oversee its delivery.

Outcome

Components shared across 80 sites, an estate consolidated into three, new projects starting from a self-service template instead of a blank page, and a CMS project delivered. On my CV it’s one line, “Transformed over 80 active sites”, but it was really four layers: standards, a template, shared components and a shared platform.

What I’d do again

• Ship standards as defaults, not documents. The accelerator did more for consistency than any guideline.
• Self-service from day one. Removing the ticket queue is what got teams to adopt the road.
• Keep shared parts as packages, not just a template. A copied boilerplate drifts; a versioned component library and shared config don’t.
• Treat documentation as product. It was the part that outlived my time on the team.

Looking back, this was platform engineering before I had the words for it: a golden path, self-service provisioning and a shared component layer, all in a supporting domain (Where Platforms Fit: DDD Subdomains). It’s also where I first saw Building Digital Culture’s point in practice: the tooling only worked because the team’s habits changed with it.

Related notes

Web Accelerator · Internal Developer Platform · Storybook · Headless Component Libraries · Golden Paths