A+ ships around 55 fixed module types, which constrains brands to rigid layouts. So many brands design their content in Figma or Canva instead, flatten the result, and upload stacks of full-width images that can't be searched, don't work with screen readers, and can't be moderated. Nearly half of all projects are built this way. Everyone understood the customer problem. What didn't exist was a technology strategy to fix it, and that gap is what my design filled.
This is also the project that the two before it set up: the design-system migration gave the front-end one system to build on, and a schema layer I built gave it the module definitions the new editor consumes directly.
Setting the Strategy
As the sole author, I defined the front-end design for Dynamic Content: a WYSIWYG canvas editor, recursive block composition, responsive styles at three breakpoints, a token-based design system, and a universal renderer for the detail page.
- Drove the build-vs-buy decision to closure over a six-month alignment effort that I owned end to end. Before committing to a direction, I arranged and led four competitive-analysis consultations to pull in prior art: three with internal teams and one with an external vendor. The findings became the decision doc that secured a Director-level call to build our own next-generation editor rather than take an external dependency, while opening our APIs so third-party tools can still create content.
- Authored the design as a decision record: the problem backed by data, options weighed with explicit tradeoffs, recommendations with rationale, and a phased launch plan with hard gates.
The Architecture
- Defined the architecture for 12 packages across 2 teams and split the work into parallel streams so the editor and renderer teams can execute independently.
- Resolved constraints that genuinely conflict: two rendering stacks (the React editor and a server-rendered detail page) that must match within 1% pixel parity, a shared schema consumed by 15 downstream systems, backward compatibility with existing content on the same detail-page slot, and forward portability for third-party import and export.
- Set performance budgets for canvas render and block-insert latency, and added an auto-scaling rule that prevents broken mobile layouts by default.
The Foundation: Module Centralization
Dynamic Content is only viable because of a schema layer I built first. A+'s module definitions used to live only in the front-end, duplicated across 8+ codebases in three languages, so no other system could validate or render a module without going through us.
- Built a single cross-language source of truth that every application and service can consume module schemas, constraints, and config from.
- Changed the cost of adding a new module from O(n) to O(1): from three implementations across 8+ packages down to a single schema definition.
- Cut the schema bundle about 40% by pre-computing schemas at build time instead of on every editor render.
Result
The design projects about 67% less engineering overhead per new layout: a new template becomes a schema-only definition, with no editor code and no renderer code, versus today's schema plus editor plus renderer. It also unlocks things the per-module model never could, like third-party import and export and a template library that scales without engineering work. The schema layer is unblocked, the first editor primitives are in progress, and a beta is targeted behind a feature flag.