The starting problem was simple but costly. Even a small homepage or layout change still required an engineering ticket, release timing, and coordination across teams.

This was never only about content management. It was about product autonomy: giving product the ability to test, learn, and ship routine layout and campaign work without waiting on sprint capacity.

This was bigger than just updating props or moving items around on a page. I framed it as a foundation that could eventually power a personalization system that adapts modules and layouts to each user's behavior and context.

I set out at first to evaluate vendors and a path forward for a CMS, mapping each problem to the insight that shaped how I thought about a solution.

As I worked through it, I realized a vendor would be costly and still leave us with significant integration work. Given what was actually being asked for, and where the industry and AI tooling had gotten to, it started to make far more sense to build instead of buy in this case.

The first proof point was not a full multi surface CMS. The team started by rebuilding the homepage to run entirely off a JSON configuration, which gave us a concrete way to test whether structured page composition could replace hardcoded layouts.

From there it transformed into a full blown AI editing studio. It was far more than a chat box: a PM described the change they wanted in plain language, and the edited page rendered right next to the conversation so you could watch your changes happen in real time. Behind that live preview was an iframe previewer that loaded a real page, injected the updated config JSON over postMessage, and forced a live re-render as you authored.

You could also click directly on elements in the page to see what was editable, or to point the chat at exactly the section you wanted it to focus on. When a change was ready, the studio could automatically place it behind a feature flag or experiment, so it shipped through our normal rollout and testing model rather than going straight live.

Everything ran off a structured JSON schema, and that was the key constraint. The schema was all Claude could touch: it composed approved components and props into approved slots, with no free form code generation and nothing outside those guardrails. It was intentionally limited, not magic.

To keep that safe, a second Claude instance acted as a validator. Before any change was previewed or applied, it checked that the generated JSON was correct, schema compliant, and free of issues, giving us a second set of eyes on every edit without a human in the loop.

The point was to prove this could behave like a real CMS for product users while staying grounded in our component library, validation rules, and deployment pipeline.

The core architectural bet was "AI as CMS" rather than "buy a CMS and adapt around it." The execution moved through a few clear stages.

• Evaluate the market. Assess established CMS vendors like Storyblok and Contentful to understand the trade-offs around experimentation, security, plugin ecosystems, and operational complexity.
• Build the internal foundation. JSON-driven configs, schema validation, a visual editor, PR-based publishing, sandbox preview, Slack approvals, and CDN-backed delivery.
• Put it on a real surface. The system was soon managing portions of the Realtor.com homepage in production behind a feature flag, as a controlled rollout.
• Learn, then scale. Use that production foothold to tighten workflows and decide whether to expand to surfaces like global navigation and listing pages.

This is an important difference from Oracle. Oracle was a page rewrite with a large public traffic ramp; the AI CMS was a capability platform that had to prove safe adoption and workflow fit before broad expansion.

Every layer was chosen to give product teams agility without surrendering performance, consistency, or control.

The platform has a strong thesis and a real production foothold: it is already managing portions of the homepage behind a controlled feature flag, it saves roughly $145K a year in CMS licensing, and it keeps AI cost minimal.

Early modeling suggested that the reduction in engineering dependency, plus faster campaign deployment, could offset build cost within six to nine months.

We set explicit success criteria: fewer tickets and less developer time for content changes, faster time from campaign idea to live deployment, no degradation in Core Web Vitals, server response, or SEO health, and wider adoption across page types and teams.

The honest read is a strong platform in motion: a real production foothold and a clear roadmap, with full-scale adoption still ahead.

I reframed the project from "should we buy a CMS?" into a product-velocity and platform-control problem.

I identified that our real requirements were not generic editorial needs. They were experimentation, governance, performance safety, and deep integration with our existing design and deployment stack.

The project also turned design into a leverage point instead of a bottleneck. Design defines the module library, slot rules, and compositional constraints, so valid AI-generated output is approved by construction.

And it was built on systems we already know how to operate: GitHub, CI/CD, Slack, AWS, and our existing UI and AI platform investments.

The strongest lesson is that this was never really a CMS project in the narrow sense. It was a controlled autonomy project for product teams to increase velocity.

The second is that structured data mattered more than the editor brand. Once we accepted that pages had to be driven by structured config either way, the question shifted from "which CMS?" to "which operating model gives us the most leverage?"

• AI only works safely when design and engineering define the boundaries up front. The win condition was autonomy inside a constrained component-and-slot system, not unconstrained generation.
• Vendor products were not rejected for being weak. They were rejected because their strengths did not line up with our hardest requirements: experimentation fit, lock in concerns, and workflow integration.

By this point the project had crossed the threshold from idea to operating system: real production homepage usage, a defined rollout path, and a roadmap from basic slot orchestration toward personalization.