What I built at Contentstack.

My first brief at Contentstack wasn't one project — it was three. The company needed rich text editing across two very different worlds: a legacy Angular CMS and a brand-new headless CMS, and one editor couldn't speak to both. So the answer was three editors, each speaking a different format — an HTML-based editor for the legacy product, a JSON-based editor for the future, and a Markdown-based editor for the headless CMS — complete with drag-and-drop, inline editing, and asset management.

The hard part wasn't writing three editors — it was making one mental model span three output formats without becoming three separate messes. I designed a JSON-configurable dynamic toolbar so new capabilities could be added through configuration rather than code, and a shortcut module that let Markdown shortcuts work directly in the editor, without anyone ever opening the toolbar.

All three shipped before I started full-time. The JSON editor went on to become one of the most capable rich text editors in the headless-CMS space — the foundation the rest of my work at Contentstack would build on.

Before Live Preview existed, editing content was a leap of faith. To see how a change actually looked on your site, you had to save or publish it first — a slow, risky loop that put unfinished work one wrong click away from production. The brief was deceptively simple: let content managers preview their unsaved edits on their own live website, in real time, with nothing committed to an environment.

This was my first solo project, and I owned it end to end — figuring out how to stream unsaved CMS changes into a customer's live site, building the feature itself, and shipping a fully-typed SDK so the developers integrating it got autocomplete and lint errors instead of guesswork. I wrote the documentation too.

The constraint that shaped everything: do it with no new infrastructure — no websockets — to keep it cheap and reliable at scale. That ruled out the obvious solution and forced a more elegant one. I used postMessage channels for communication between the CMS and the customer's site running in an iframe, a broadcast channel to keep state in sync across multiple tabs, and field tagging so the preview could map any rendered element back to the exact CMS field that produced it — the thing that makes click-to-edit possible.

Live Preview became one of Contentstack's most successful features. It closed deals, and it nudged the entire headless-CMS industry toward visual, in-context editing as the expectation rather than the exception.

Contentstack's extension framework is the engine that lets third-party apps appear and work inside the CMS. By this point it needed to scale in ways its original design couldn't, and it was due for a ground-up rewrite — for performance, and for the kind of long-term maintainability a team can build on for years.

That rewrite is what earned me a double promotion to Software Engineer 2, skipping a level entirely. I reimplemented the framework around reusable, standard components and wrote the modern App SDK using the same typing-first principles I'd established with the Live Preview SDK — so external developers could build apps with custom behaviour inside Contentstack.

The real challenge was the boundary. The framework had to host arbitrary third-party UI in every location of the CMS without leaking, breaking, or compromising the host — a flexible, well-typed contract between the platform and the apps running on top of it, stable enough that the team could keep building against it long after I'd moved on.

The rebuilt framework became the base for the new Marketplace and Developer Hub — the platform layer that turns Contentstack from a product into an ecosystem.

When the AI wave hit, Contentstack set out to ship its first AI product — the AI Assistant, delivered as a Marketplace app. There was a catch that had nothing to do with models or prompts: none of the existing UI locations could actually host it.

So I designed and built two new UI locations in the extension framework — Field Modifier and Full-page — and extended the App SDK to support them, delivering the whole end-to-end flow in under a quarter.

Honestly, the build itself wasn't the hard part — the pressure was speed. Both new locations and their App SDK support had to land, end to end, fast enough for the AI Assistant to launch on schedule. The framework I'd rebuilt in the previous chapter is exactly what made that pace possible: new surfaces could be added without re-litigating the foundations.

Field Modifier and Full-page shipped and powered the AI Assistant — Contentstack's first AI-powered feature.

Live Preview had proved there was real appetite for visual editing. Its successor, Visual Builder, would go further: let users compose and edit entire pages visually, not just preview them. That ambition needed an architecture that could carry the weight.

I was brought in to architect Visual Builder, drawing on years of iframe and postMessage experience from Live Preview and the Extension Framework. I designed the framework and built it to a working prototype. The Advanced PostMessage and Advanced Broadcast packages I wrote — released as open source — power the communication layer behind both Live Preview and Visual Builder.

Visual editing is one of the genuinely hard problems in this space: you're orchestrating an untrusted iframe, the parent window, and multiple browser tabs in lockstep — reliably, and without paying for extra infrastructure to do it. Every sharp edge I'd hit building Live Preview and the Extension Framework was a lesson that went straight into this design, and the Advanced PostMessage and Broadcast packages are what made that cross-context communication robust and reusable instead of a one-off hack.

Visual Builder superseded Live Preview as Contentstack's visual-editing experience — carrying the story forward from a proven feature into a first-class product.

New users needed a place to learn the platform — a polished developer experience that made onboarding feel effortless. Contentstack Academy 2.0 was that product.

I designed and developed Academy 2.0's architecture and planned its execution and release — from initial requirements to launch in six months. I owned the backend, and I set the bar for the team: craft the most beautiful DXP we could.

On paper it was a fairly standard build, so I deliberately set a harder, less technical challenge: make it experiential, not just functional. The onboarding had to be frictionless and beautiful enough that the product effectively taught itself — the absence of friction is the feature.

Designed, built, and released in a single half-year — a complete learning product, end to end.