Why we moved mardi.work from vanilla JS to Next.js
A strategic look at why we migrated mardi.work to Next.js, with a focus on operational consistency, maintainability, and a cleaner foundation for measurement.
Introduction
We moved mardi.work from vanilla JS to Next.js for one reason: operational alignment.
The previous site was functional. This was not a rewrite driven by fashion or framework enthusiasm. The issue was that the website had become a technical exception inside an environment otherwise built around a more modern and consistent product workflow. Over time, that kind of exception creates friction that is small in isolation but expensive in aggregate.
The migration was therefore less about changing the website’s visible surface and more about improving how the site fits into the way we build, maintain, and measure digital products.
Technology strategy
The main technology decision was to reduce fragmentation.
A separate stack for a company website can be acceptable when the site is static, rarely updated, and operationally isolated. That was no longer the right fit for mardi.work. As the broader environment around the business became more standardized, keeping the website on plain HTML, CSS, and JavaScript meant maintaining a different set of patterns, tooling habits, and deployment expectations for a business-critical surface.
That creates unnecessary overhead. Even simple changes require context switching. Maintenance becomes less predictable. The website gradually behaves like an exception instead of a system component. From a leadership perspective, that is rarely a good long-term tradeoff unless the exception provides a clear advantage. In this case, it did not.
Moving to Next.js created a more unified foundation with the rest of our workflow. The benefit is not framework prestige. The benefit is consistency across development, deployment, and iteration. When multiple products share similar conventions, teams move faster, onboarding is easier, and changes are less likely to introduce avoidable complexity.
Maintainability was the second strategic factor. A website that follows the same structural logic as the rest of the environment is easier to extend and easier to keep coherent over time. That matters more than initial build speed. Most technical inefficiency comes from ongoing change, not from first delivery.
Measurement also became cleaner. Because the site now sits more naturally inside the same ecosystem as the rest of our tooling, analytics integration is simpler and operationally more reliable. That is important because visibility should not depend on custom setup that has to be remembered and maintained separately.
This was ultimately a consolidation decision. We traded a standalone implementation for a more coherent platform fit.
Product strategy
From a product standpoint, the website is not separate from the business. It is one of its most visible product surfaces.
That means the relevant question is not whether visitors notice the framework. They do not. The relevant question is whether the site can be updated, measured, and improved with the same discipline as the rest of the products we operate. When the answer is no, the website tends to fall behind in small but important ways: slower updates, less consistent messaging, weaker instrumentation, and more hesitation around incremental improvements.
The migration improves that operating model. A website that is easier to maintain is more likely to stay accurate. A website that is easier to evolve is more likely to support changing positioning, offers, and content needs. A website that is easier to measure is more likely to inform better decisions rather than simply exist as a brochure.
There is also a strategic consistency benefit. When the website shares the same general foundation as the rest of the company’s digital products, brand, product thinking, and execution stay more closely aligned. That does not make the website more complex for its own sake. It makes it easier to manage as part of a broader system.
The product value, then, is operational leverage. Internal simplicity leads to better external consistency. That is what makes this kind of migration worthwhile.
Conclusion
We moved mardi.work to Next.js because the previous stack had become an operational outlier.
The migration was not about novelty. It was about consistency, maintainability, and cleaner measurement inside the workflow we already use to build products. The visible result may be modest, but the structural result is more important: the website is now easier to manage, easier to evolve, and better aligned with how mardi.work operates.