Leading Meltwater's publishing frontend

The product

I was a lead frontend engineer on Meltwater's publishing product. Social teams used to draft, schedule, and publish across different accounts from one calendar section, and handled replies and comments without leaving the application.

The stack comprised of Vue with Stencil web components on a micro-frontend. We used FullCalendar to handle most of the calendar section. I owned rendering, the flows around it, platform validations, in-flow media editing, and an AI assistant for helping with 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 copy, media, or timing without leaving the view.

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

Crop and trim lived in the same flow. I shipped an AI assistant for writing and tagging. Suggestions stayed optional and needed an explicit accept or reject before anything went live.

Calendar week view

Product wanted week view vertical. FullCalendar v3's web component build did not support that layout. Day and stacked views could stay on the library. The week view could not. A full migration costed around $200K and three months of dedicated work.

I built a custom week-view renderer instead. Drag-and-drop, event handling, and view switching stayed intact, synced with FullCalendar's internal data structures. The full write-up is in the week-view renderer case study.

Shared component library

Several product teams had rebuilt the same UI in their own stacks. Buttons, dropdowns, modals, and inputs existed in multiple places with no shared source. The look drifted, and every fix got repeated.

I worked on a shared Stencil web components library 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 and semantic versioning so fixes landed once.

Performance under load

Some accounts started hanging. A single tab sat around 2.65GB of RAM. Support suspected the calendar could not handle large schedules. Heap snapshots and performance traces said otherwise.

I traced detached DOM under Shadow DOM, long main-thread tasks, modals that mounted closed and leaked on reopen, and an unvirtualized tags list on the order of 10,000 items. Lazy-loaded modals plus cleanup brought memory to around 600MB. List virtualization settled it around 200MB. More detail is in the memory optimization case study.

Outcome

Validations, in-flow media editing, and the AI assistant shipped on top of an already busy calendar without a stack rewrite. Week view went vertical with a scoped renderer. Memory held near 200MB under continued use. The shared library cut duplicated UI work across teams.

The approach stayed the same across all of it. Measure first, rule out the easy theory, and own the hard path only where the existing stack could not go.

Testimonials

Jordan IraborSenior software engineer @ Meltwater

I had the pleasure of working with Parmeet on the same team at Meltwater, and I can confidently say that he is one of the best engineers I've worked with. Parmeet brings an exceptional level of attention to detail, a deep understanding of software engineering, and a curiosity that inspires overall team improvements. He approaches every sprint with a holistic mindset, considering not just the immediate implementation but also the broader product impact. Parmeet consistently contributes thoughtful design suggestions and explores alternative approaches, clearly outlining trade-offs and helping the team make informed decisions. He's not one to shy away from challenges and frequently demonstrates leadership through initiative, insight, and collaboration. His ability to balance technical depth with product thinking makes him an invaluable asset to any engineering team.