The Liberal Party of Canada’s candidate multisite was a WordPress installation built to do something most political-tech vendors of the era treated as impractical: spin up an independent, candidate-owned campaign website for every Liberal candidate running in a federal election. One platform, hundreds of subsites, each one looking and feeling like the candidate’s own.
The problem
A federal election in Canada means a national party has to put a campaigning candidate in every riding it’s contesting: three hundred-plus separate campaigns, each rooted in a different community. Every candidate needs a web presence, none of them are web developers, and the campaign has weeks, not months.
The political-tech answer at the time was usually one of two compromises: either a centrally-controlled microsite that treated every candidate as a row in a database, or a recommendation that each candidate hire their own web person and good luck out there. Neither answer served the candidate or the party.
The build
The platform was WordPress Multisite. One central installation, riding-specific subsites generated and provisioned for every candidate in the country. The central party kept the underlying theme, plugin set, and shared content components in lockstep; the candidate and their team got a working site they could customise (biography, policy positions, riding photographs, events, volunteer-recruitment forms) without touching code.
The interesting craft was in the seam. Subsites were independent enough that they read as the candidate’s own site, not as a slice of party branding. They were standardized enough that the party could push a security patch or a shared component across every site in the country in one operation. Multisite is the tool that makes that seam possible at WordPress’s scale.
I was part of the team that built it, not the sole architect. National-scale political tech is always a team build.
What it taught me
Most of the WordPress work I do now still draws on what this engagement made obvious. Multisite isn’t just a hosting convenience; it’s a content-architecture decision about who owns what, who can change what, and where the seam between centrally-controlled and locally-controlled content actually sits. Get that seam wrong and you either get a system the central team has to babysit forever, or a system the local site owners can’t actually use.
I still spend most of my WordPress development engagements working out a version of the same question. Multisite was the right answer for this one. On most projects it isn’t, and the real work is figuring out what is.