I was the lead frontend engineer on a publishing product. Social teams used it to draft posts, schedule them across accounts and regions, publish to multiple platforms, and manage replies, comments, and likes without switching tools.
Week, month, and stacked views gave them one place to plan what was going out and when. Some accounts carried hundreds of posts at once, so the UI had to stay fast under real load, not just look complete in a demo.
I owned the frontend for that surface end to end: calendar rendering, the flows wrapped around it, platform validations, and performance as the roadmap kept growing.
The stack was Vue with Stencil-based Web Components. FullCalendar v3 powered day and stacked views. Week view was the exception. Product wanted a vertical layout the library did not ship, which later pushed us toward a custom renderer.
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 also crop images or trim video in the same flow. I shipped an AI assistant to help write posts and tag people. It was optional throughout. The UI surfaced what the model suggested and required an explicit accept or reject before anything went live.
Compose, preview, and schedule across platforms from one modal.
The calendar had to stay fast even with dense week and month schedules.
When the vertical week view landed, I compared a full library migration, roughly $200K and three months of work, against extending FullCalendar. I led the custom renderer path so drag-and-drop, event handling, and view switching still worked. The full breakdown is in the week-view renderer case study.
A separate performance crisis hit enterprise accounts with large schedules and tag lists of 1000+ items. A single tab climbed to 2.2GB RAM and put about $60K MRR at churn risk. I traced detached DOM nodes, main-thread long tasks, and an unvirtualized tags list, then shipped lazy-loaded modals, cleanup for detached elements, and list virtualization. Memory settled around 200MB. That work is covered in the memory optimization case study.
The product held up as we added 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. Both were frontend problems inside the same surface I led, and both shipped without pausing the rest of the roadmap.
Vue with Stencil-based Web Components on a micro-frontend surface. FullCalendar v3 for day and stacked views, plus a custom week renderer where the library could not meet the layout requirement.
OR
Write To Us At Your Own Convenience