PLATFORM ARCHITECTURE · Jan 2020–2025
Modernizing a legacy frontend across teams
Helped define a shared microfrontend approach across teams, migrating legacy Backbone experiences to React while owning the build, maintenance, deployment, and CI/CD pipelines for 5+ microfrontends.
Autodesk
Software Engineer IV → Lead Software Engineer
observed page-load time
reduction in average CI build time
My role and ownership
I joined Autodesk in January 2020 as a Software Engineer IV, focused on frontend architecture. After approximately one year, I moved to another team and was promoted to Lead Software Engineer. I worked with team leads and principal engineers to define a shared microfrontend approach using Webpack Module Federation, wrote ADRs, and mentored engineers.
I was responsible for building, maintaining, and deploying more than five microfrontends and their CI/CD pipelines. These supported purchasing, subscription and contract management, user and permission management, and product downloads. Other team leads owned their respective areas of the wider system.
The legacy system and migration
Much of the existing application was written in Backbone. It lived in a Lerna monorepo, used Yarn workspaces for development, and relied on a legacy toolchain that included Bower. Bundling the application together made the development and delivery workflow slow.
We first migrated Backbone experiences to React 16 while retaining the monorepo and Yarn workspaces. Slow builds and shared releases then became bottlenecks: merged features that were not ready to launch could block other teams. We subsequently adopted microfrontends with Webpack Module Federation, with team leads responsible for distinct areas. A later React 18 upgrade was a separate migration.
A reusable loader and communication across frameworks
I built a private npm MFE loader so teams could load and render microfrontends through configuration instead of repeating integration logic. The loader handled rendering failures gracefully and supported lightweight communication through native browser APIs. I proposed browser events as a publish/subscribe mechanism that teams using React, Angular, or Vue could share.
Before relying on that approach, I reviewed browser usage metrics for our users to assess compatibility and determine whether a polyfill would be needed. The decision had to fit the browsers our customers actually used.
Feature flags and shared rollout tooling
We used LaunchDarkly feature flags to control the rollout. I scaffolded a reusable library for fetching feature flags and published it to Artifactory so other teams could consume it.
That work extended beyond my own microfrontends: it provided shared tooling that teams could incorporate into their applications as the migration progressed.
Balancing UX, architecture, and delivery
Some proposed UX flows did not fit the architecture within the available delivery timelines. I pushed back on those proposals and negotiated scope with UX, weighing the desired experience against the architectural work and time required to deliver it.
Leading the migration meant working through those tradeoffs with other teams while continuing to build and maintain the applications I owned.
Measuring the outcome
I established a performance baseline with Chrome DevTools, including paint timing, and compared measurements after deployment. I also used monitoring tools such as Dynatrace to track JavaScript errors.
After deployment, observed page-load time dropped from 6 seconds to 1 second. We also saw fewer JavaScript errors, alongside fewer support tickets. Average CI build time decreased from 40 to 15 minutes, approximately a 63% reduction. Teams could deliver independently, reducing release coordination. In the month following the microfrontend transition, the engineering-debt backlog fell from more than 100 tickets to roughly 60.
Interested in working together?
Start a conversation