Building on the platform instead of around it: Mosaic micro-frontends, Shaka Player DRM, and a ~15% faster load.

01 · Context

Axinom builds enterprise media technology, and its internal platform — Mosaic — already exposes the hard parts of media delivery as micro-frontends: Media, Catalogue, Entitlement, and DRM. I led the frontend team delivering high-performance web applications on top of it for clients including the Goethe-Institut and the Lindau Nobel Laureate Meetings, whose Mediatheque holds decades of lecture recordings from Nobel laureates and young scientists. Two things make that work harder than a normal web build. Protected content has to actually play, on real devices, through a DRM pipeline that fails loudly and unhelpfully. And the audience is international, so every string, layout, and format is a localization problem, not an afternoon of translation.

02 · The decision

I made building on the platform the default rather than the fallback. Client film and audio content ran through Mosaic's micro-frontends and Mosaic APIs for content synchronization and metadata management, and secure playback went through Shaka Player so DRM was handled by a hardened player rather than a bespoke integration. i18n was designed in from the start instead of retrofitted. On top of that I treated load time as a first-class deliverable — bundle optimization, lazy loading, and caching improvements — rather than something to look at after launch.

03 · The trade-off I made

Reuse the platform vs. build it bespoke. Mosaic's micro-frontends come with their own conventions and integration seams, and there were moments a hand-rolled component would have been quicker for one client. I chose the platform anyway: bespoke media delivery means owning DRM edge cases and metadata sync forever, and that debt lands on whoever inherits the codebase. Where the platform genuinely didn't fit, we extended rather than forked — and I weighed each of those against the maintenance cost out loud, in client and internal reviews.

04 · What I measured

Page load time was the number I could defend, measured before and after the bundle work, and it moved ~15%. Alongside it I watched playback through the player's own failure taxonomy and the support tickets that reached me — which is exactly the weak instrumentation I name elsewhere, cross-region rendering once i18n was live, and the CI/CD pipelines I kept stable with DevOps — because a performance win that ships unreliably isn't a win. Delivery health was tracked in Azure DevOps and JIRA, with the process documented in Confluence.

05 · Outcome

Two client products delivered 0→1 through full development, testing, and production release cycles; ~15% faster page loads from bundle optimization, lazy loading, and caching; multi-language experiences shipped across regions; and protected content playback via Shaka Player and DRM workflows. Alongside the delivery work I strengthened the security posture by identifying vulnerabilities and adding validation and authentication layers, and mentored junior developers while enforcing coding standards.

06 · What I'd do differently

What I'd do differently: I measured page load as an aggregate for too long. Averages hide the regions and devices where the experience is materially worse, and on an international media product that's exactly where the users you're localizing for live — I'd segment by region and device from the first measurement, not the third. The broader lesson: on a platform like Mosaic, the engineering skill isn't writing more code, it's knowing which capability already exists and integrating it cleanly enough that the next team doesn't rewrite it.