Platform architecture
Rebuilding our own website into a working platform
Why JMG Group rebuilt its own site from the ground up, and what that process reveals about the shift from a conventional website to an integrated digital system.
JMGGroup.ca had grown over many years into a site that no longer matched how we actually work. It described a digital marketing and SEO consultancy, and for a long time that was accurate. But the work had moved on — into product architecture, AI-assisted development, automation and integrated platforms — and the site had not moved with it.
Why we rebuilt rather than redesigned
A redesign changes the surface. A rebuild changes what the site is capable of. The decision here was the second one: rebuild around the way we work now, so the site behaves like a product — clear to navigate, easy to publish to, and able to keep growing without fragmenting.
The practical difference shows up in maintenance. On the old site, publishing a new service meant editing navigation, a sitemap, an internal-link block and metadata separately. On the new one, those are outputs of a single content definition.
What changed on the surface
The most visible change is the visual language. We moved away from a conventional marketing-agency aesthetic toward something systems-oriented and editorial — deep ink surfaces, a single teal accent, blueprint and grid language, and animated system diagrams that describe how the pieces fit together.
The intent was not decoration. It was to make the site feel like the kind of platform JMG Group builds for others, so the positioning is legible before anyone reads a paragraph.
What changed underneath
Less visible, but more important, is the architecture. Adding a service, a project or an article does not require rebuilding navigation, sitemaps or metadata by hand:
- One source of truth feeds the HTML sitemap, the XML sitemap and internal links.
- Each page carries its own title, description, Open Graph metadata, canonical and structured data.
- Routes are typed, so a link to a page that does not exist fails at build time rather than in production.
- Legacy URLs from the previous site resolve through permanent redirects instead of 404s.
One content model, many outputs
Site versus platform, in practice
| Conventional site | Working platform | |
|---|---|---|
| Adding content | Manual edits in several places | One definition, propagated everywhere |
| SEO metadata | Per-page, hand-maintained | Generated from the content model |
| Internal linking | Ad hoc, decays over time | Derived from real relationships |
| Growth cost | Rises with every page | Roughly flat |
| Failure mode | Silent drift | Build-time errors |
Before and after: site to platform
Where AI-assisted development actually helped
AI-assisted development compressed the distance between an idea, a working prototype and a validated system. That changed what a small, senior team could realistically build and maintain.
Experience still guided the decisions. AI increased execution capacity; the fundamentals — what to build, what to leave out, and what a system needs to survive its second year — did not change.
The continuity underneath
The foundation the site is built on is the same one JMG Group has worked from since 2001: websites, search, digital marketing, lead generation and publishing. The tools changed. The underlying experience did not. That continuity is why the rebuild could move quickly without losing coherence.
If you are considering a similar rebuild, the useful question is not whether the site looks dated. It is whether the site still represents how the business actually operates — and whether it can absorb the next two years of growth without being rebuilt again. The full breakdown is in the JMGGroup.ca redesign case study, and the underlying approach is described in application and PWA development.
Frequently asked questions
- When is a website rebuild actually justified?
When the site no longer represents how the business operates, or when routine changes — adding a service, a case study, an article — require manual work in several disconnected places. A dated appearance alone is a redesign problem, not a rebuild problem.
- What is the difference between a website and a working platform?
A website presents pages. A platform is structured so that content, navigation, search metadata and internal linking all derive from shared data, which means it can grow without being re-engineered. That distinction is the subject of from fragmented stack to integrated platform.
- Does a rebuild mean losing existing search visibility?
Not if URL structure, redirects, canonicals and content depth are planned before launch. Legacy paths were mapped to permanent redirects during our own rebuild, and every page carries a self-referencing canonical and its own structured data.
- How much did AI-assisted development change the process?
It shortened the distance between an idea, a working prototype and a validated system. It did not replace judgement about what to build, what to leave out, or what a system needs to survive its second year.
- Can this approach work for a small team?
Yes — it is arguably more valuable for a small team, because the architecture carries work that would otherwise need a person. That is the same principle behind our automation and business systems work.