Why We Rebuilt Our Page Engine Instead of Building a Third One
A look at ADR-025: how SmartAgents chose to generalize its existing Cms\Page engine rather than ship a second, parallel page/template system for a new product line.
When a new product line needed its own pages and templates, the easy path was to build a second, parallel system next to the one already running the main site. We didn't take it.
Architecture Decision Record 025 documents why: SmartAgents already had a working `Cms\Page` + `PageBlock` model powering the main site's no-code editing. Standing up a second, incompatible page/template family would have meant two things to maintain, two mental models for the team, and a migration headache the first time a page needed to move between them.
Instead, the decision was to generalize the existing engine -- adding tenant scoping, a template/theme layer, and no-code block configuration -- so every product on the platform, present and future, shares one page engine. The work is split into two sprints: first the generalization itself, then the Content Collection Engine that extends the same foundation to repeatable content types like news, blog posts, and job listings.
The same review also surfaced a related gap: job listings, news, and blog posts don't fit neatly into "one-off marketing pages." They're collections -- items that get added, listed, and retired over time. That became its own approved capability, built on the same reconciled foundation rather than as a third parallel system.
For a platform vendor, this kind of decision is boring by design. Nobody outside engineering notices it happening. But it's the difference between a platform that stays maintainable at year three and one that's accumulated three incompatible ways of doing the same thing.