Frontend: from monolith to product applications
In 2016, the public site was a React monolith with a common repository, infrastructure and release. At first, the team did not rewrite it entirely: they identified repeatable blocks, forms and tracking, made common components and agreed on contracts. New product parts were created nearby, and old ones were gradually transferred to the platform.
As product teams grew, they were given separate applications, repositories, and release responsibilities. Common engines became dependencies that were developed by the core team according to the internal product model. Microfrontends appeared here not as a technology for the sake of technology, but as a coincidence of the boundaries of code and ownership. Independence required versioning, documentation, compatibility, and a clear update path: without this, the common platform just moves the central bottleneck to another repository.
CMS and content without app release
The old CMS was closely tied to templates and frontend release. The page change went through development and general release, so marketing hypotheses were waiting for the engineering cycle. The new model presented the page as a composition of known blocks with a verifiable configuration. Editors were able to collect and publish content without releasing the application, and developers focused on developing blocks, contracts, security and platform performance.
The transition was also gradual: the new system picked up scripts one at a time while the old one continued to serve the rest. A team that both understood the architecture and worked with real editors and products was essential. An isolated group of architects might design a clean but inconvenient system. The platform becomes useful only close to consumers, and its roadmap is formed from repetitive tasks and measurable reduction in publication time.
Personalization and evolutionary lessons
At first, personalization was based on manual rules and A/B tests: the segment determined the page option, events connected the impression with the application, and statistics chose the winner. With the growing number of products and simultaneous experiments, a platform was needed that could resolve conflicts, conduct audits, and calculate the results. The next step is a predictor on Vowpal Wabbit, which selects an option based on the user’s context. ML turned out to be an extension of a reliable experimental loop, and not a replacement for analytics.
The main lesson is that architecture and organization change together. New application boundaries required product owners, platform teams, and compatibility rules; independent editors - new contracts and control; personalization of the general data infrastructure. A large system cannot be improved by one revolution: you need to maintain business flow, build a new opportunity nearby, transfer customers and remove the old one. Each stage must provide benefits until the entire target picture is completed.
What to take away
- 01Evolutionary migration preserves the food supply: a new solution first proves its value next to the old one.
- 02Microfrontends are useful when application boundaries coincide with ownership and independent release of teams.
- 03A release-free CMS decouples the speed of content hypotheses from the engineering cycle while maintaining verifiable platform contracts.
- 04ML personalization makes sense on top of mature events, experiments, and analytics, not instead of them.