Multiphase Website
Replacing a WordPress site I had built myself, before it became the problem I had just watched happen somewhere else.
Rebuild, architecture decisions, ongoing maintenance
Multi-Phase Industrial & Infrastructure Projects
2026
Astro, Sanity, React, TypeScript, styled-components
I built Multiphase's first website on WordPress. It worked, and for a while that was enough.
Three things changed. The site had become slow and awkward to edit, so updates stopped happening. The company was about to have a workforce portal with live job postings, and there was no sensible way to get those onto a WordPress marketing site. And I had just watched what happens when nobody maintains a WordPress install.
The obvious fix was an off-the-shelf applicant tracking system. That fix was unavailable, and understanding why is the whole project.
Another client's WordPress site was exploited. Nobody had been patching it, there was no one internally whose job that was, and the first anyone knew about it was a browser warning telling visitors the site was dangerous. That is how I came to work with them.
Multiphase had the same exposure. A WordPress install, no internal IT, and a maintenance task that only existed as long as someone remembered to do it. The difference was that I could see it coming rather than arriving after the fact.
So the rebuild wasn't a redesign. It was removing a category of risk.
Four decisions, from static output to selective JavaScript.
Static output, so there is nothing to attack
The site is generated as static files by Astro. There is no PHP runtime, no database behind the public pages, and no plugins. The class of vulnerability that took the other site down cannot exist here, which means the company's security no longer depends on anyone remembering to apply an update.
A headless CMS, so I am not the bottleneck
The easy version of a static rebuild makes every content change a code change and a deployment, which quietly makes the developer a permanent dependency. Content lives in Sanity instead, so their team edits the site themselves and the build picks it up. They got the security improvement without losing the thing WordPress was actually good at.
Wired to the workforce portal
The platform publishes open roles through a public feed. The website consumes it, so a job published in the portal appears on the public site without anyone copying anything across. The marketing site and the internal system are two halves of one thing rather than two sites that happen to belong to the same company.
React only where it earns it
Most of the site is static HTML. Interactive components exist where they do something, not as a default. That keeps the pages fast on the connections their visitors actually have.
Live at multiphaseprojects.ca and in regular use. Jobs published in the workforce portal appear on it automatically.
I built the original and I replaced it.
That is the part worth knowing. The first version solved the problem as it looked at the time, and when the circumstances changed I did not defend the work I had already done. This was a rebuild rather than engineering from nothing, and I directed an AI-assisted build rather than hand-authoring it. What the project demonstrates is the decision: recognising that an exploited site at one client was a forecast rather than an anecdote, and acting on it somewhere else before it happened again.