Case Study
Canada Lands Company · at Evolving Web · Launched Aug 2026

Canada Lands Company

The CN Tower, the Old Port, the Science Centre — one federal Crown corporation site, built fast, on an AI-assisted pipeline from prototype tokens to Drupal SDCs.

Development
Client
Canada Lands Company Limited — a federal Crown corporation, and the owner of the CN Tower, the Old Port of Montréal and the Montréal Science Centre
Studio
Evolving Web — fast-track delivery
Role
Full-stack developer. Built the Drupal site, then the front end as SDCs and blocks for Layout Builder, plus a share of the content entry.
Team
Kushneet Kukreja, project manager · Anton Morrison, design · Dharizza Espinach, migration and back-end
Canada Lands Company homepage hero: aerial dusk view of Montréal's Old Port with the Ferris wheel, overlaid with the headline 'Enriching communities and experiences' and links to the CN Tower, Montréal Science Centre and Old Port of Montréal.

A Crown corporation nobody has heard of, which owns three landmarks everybody has. The site has to introduce the parent without upstaging the children.

Canada Lands Company is accountable to Parliament and to the public: annual reports, governance, senior management, procurement. It also owns the CN Tower, the Old Port of Montréal and the Montréal Science Centre, each with its own strong brand and its own website. So the corporate site does two jobs. It sends visitors to the attractions quickly and respectfully, in each attraction's own colours. And it serves the accountability audience — journalists, government, prospective partners — who need documents, not photography. All of it in both official languages, on a timeline that left no room for a second attempt.

CN Tower attraction component: aerial photo of the CN Tower over Toronto's shoreline beside a red info panel with the CN Tower logo, name, description and a 'Visit CN Tower site' link.
One attraction component, four theme colours. The photograph and the panel overlap on an offset grid; the brand colour is a token, not a variant.
Fig. 01
Old Port of Montréal attraction component: aerial dusk skyline photo beside a cyan info panel with the Old Port logo, name and description.
Same component, mirrored, in Old Port cyan.
Fig. 02
Montréal Science Centre attraction component: photo of a child interacting with a science exhibit beside a navy info panel with the Science Centre logo, name and description.
And again in Science Centre navy. Editors pick the attraction; the layout follows.
Fig. 03

Anton's prototype already had real design tokens in it. That single fact is why this timeline was survivable.

The usual handoff loses a week to translation: a developer reads a design, invents names for its values, and every disagreement about a shade or a spacing step becomes a conversation. Here the design arrived with its scale already declared — colours, type steps, spacing — so I carried the tokens into the theme rather than re-deriving them. The knock-on effect matters more than the time saved. Because the attraction colours are tokens, the CN Tower crimson, Old Port cyan and Science Centre navy are one component with a variable, not three components that happen to look alike.

I built the front end as Single Directory Components exposed as blocks, so the client can compose pages in Layout Builder without a developer in the loop.

Each component is one directory — template, styles, schema, props — which keeps the front end legible and means a component can be reasoned about on its own instead of being spread across a theme. Surfacing them as blocks for Layout Builder is what turns a themed site into a system the client actually owns. That decision is what the accountability pages depend on. A Crown corporation publishes on Parliament's schedule, not a developer's, and every one of these pages had to be buildable by whoever is at the desk that day.

Current portfolio panel: a light three-column grid titled 'The current portfolio' listing CN Tower, Montréal Science Centre and Old Port of Montréal, each with a colour-coded rule, name, location and one-line description.
The same brand tokens at text scale — a rule, a name, a place, two lines. No photography needed.
Fig. 04
Governance page: a senior management grid of six headshot cards, each with name, title, location and a 'view full profile' link.
Governance content: a people grid with pronouns and bilingual titles — the longest strings on the site, in the tightest cells.
Fig. 05
Reports archive page: filterable grid of annual report covers by category and year.
The reports archive. Filter by category and year — the page the accountability audience actually comes for.
Fig. 06

AI-assisted design on one end, AI-assisted build on the other. I'd like to be precise about what that actually bought us.

I used Claude to draft block and component definitions as YAML, imported them into the site, then exported the resulting configuration back out so it was properly Drupalized — canonical, versioned config rather than hand-written guesswork. Drupal's config system is exacting and unforgiving of a wrong key, and that round trip is what made generated scaffolding safe to keep. What it did not touch was the model. Which components exist, which props they take, what an editor is allowed to change, where a token belongs — those came from the design and from how the client publishes. AI wrote the boilerplate; the decisions stayed mine, and every generated file got read before it got committed.

I also did content entry, which is the fastest quality-assurance pass a front-end developer can run on their own components.

Populating real pages surfaces everything a design review misses: the executive title that runs to three lines in French, the report with no cover image, the attraction card with a logo that needs more clear space than the mock allowed. I hit those as the person filling the field, which meant I fixed them as the person who owned the component. On a fast-track project that loop is worth more than any amount of documentation. There was no time for a bug to travel between two people.