A+ ships a fixed catalog of 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. 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 a visual editor: a WYSIWYG canvas, 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 ran competitive analysis against prior art to pull in what already existed. The findings became the decision doc that carried the recommendation, with an API surface that keeps third-party tools able to 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: A Shared Schema Layer
The editor 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 schema layer shipped first, and it is what the editor is built on. A new template becomes a schema-only definition — no editor code, no renderer code — where the per-module model needed all three. That is the whole case for a schema-driven system: the cost of a new layout collapses to data.