The product

I was lead frontend engineer on Meltwater's publishing product. Social teams used it to draft posts, schedule them across accounts and regions, publish to multiple platforms, and handle replies, comments, and likes without leaving the app.

The calendar sat at the center. Week, month, and stacked views let teams plan what was going out and when. Some accounts carried hundreds of posts, so the UI had to stay fast under real load while the roadmap kept growing.

The stack was Vue with Stencil-based Web Components on a micro-frontend surface. FullCalendar handled most of the calendar. I owned rendering, the flows around it, platform validations, in-flow media editing, and an AI assistant for writing and tagging people.

Publishing workflow

Posts moved from draft to scheduled to published inside the calendar. Users filtered by account, region, or content type, then edited copies, swapped media, or changed timing without leaving the view they were already in.

Each platform had its own rules. I added upfront checks for character limits, media dimensions, aspect ratios, and URLs so errors showed before publish, with feedback specific enough to fix on the spot.

Users could crop images or trim video in the same flow. I shipped an AI assistant to help write posts, and tag people. Suggestions were optional. The UI surfaced what the model proposed and required an explicit accept or reject before anything went live.

Calendar Feature

FullCalendar v3 powered day and stacked views in its web component build. Week view was different. Product wanted a vertical layout the library did not ship, and a full migration would have cost around $200K and three months of dedicated work.

I led the custom renderer path instead. It kept drag-and-drop, event handling, and view switching intact while syncing with FullCalendar's internal data structures. The full write-up is in the week-view renderer case study.

Shared component library

Meltwater had several product teams, and each had rebuilt the same UI in its own stack. Buttons, dropdowns, modals, and inputs existed in multiple places with no shared source. The look drifted and every fix had to be repeated.

I worked on a shared library of Stencil Web Components that teams could load into Vue apps without a rewrite. We shipped 70+ documented components, kept them presentational with slots instead of props, and published through npm with Storybook docs and semantic versioning so fixes landed once instead of in every product.

Performance under load

Enterprise accounts with large schedules started hitting browser crashes. A single tab climbed to 2.2GB RAM and put about $60K MRR at churn risk. Support suspected the calendar could not handle heavy data, but the problem ran deeper.

I traced detached DOM nodes retained in Shadow DOM, long main-thread tasks, hidden modals mounting on load, and an unvirtualized tags list with 1000+ items. I shipped lazy-loaded modals, cleanup for detached elements, and list virtualization. Memory settled around 200MB. More detail is in the memory optimization case study.

Outcome

The product held up as we layered validations, in-flow media editing, and the AI assistant on top of an already busy calendar. Teams could plan across all three views, catch platform issues early, and work large schedules without the tab giving out.

The renderer work avoided a costly rewrite. The memory fixes kept high-value clients on a product they could not use before. The shared library cut duplicated UI work across teams. All of it was frontend work on the same publishing surface I led, and it shipped without pausing the rest of the roadmap.