We gave this talk at Talks by Pomelo with Andy Cuello. We told the story of how the Pomelo dashboard went from a monolith to a microfrontends architecture, and why at some point that stopped being a luxury and became a necessity.
Where we started
We started with a monorepo. For the MVP it was the best thing we could do: we moved fast and reused code everywhere. The problem showed up later, when we grew. Deploys started stepping on each other and nobody was quite sure which part belonged to whom anymore. Everyone touched everything.
How we broke it apart
When we had to add countries and products, there was no way around it: we had to split the app into pieces. We tried it two ways.
The first was to separate at build-time: different repos, NPM packages. We gained autonomy to write code, but the bottleneck was still there, because when it came time to deploy we were still tied to the same flow.
The second one, the one that clicked for us, was to integrate them at runtime. Each microfrontend became self-sufficient and gets assembled on the fly with a reverse proxy and Module Federation. That's when we could finally deploy each part on its own, without recompiling the whole app.
The hard part wasn't technical
When you decentralize, the first thing you risk losing is consistency. Every team ends up drawing its own button. So we built Paradise, our component library, with a design system behind it that keeps everything aligned even when each team moves at its own pace.
But if I had to keep one thing from all of this, it's that the biggest problem was never technical. It was coordinating people. You can have the best tools around, but if the teams don't talk to each other, autonomy turns into chaos. That's what cost us the most, and what we learned the most from.
If you're thinking about something similar or you're just curious, write me and let's talk.