Why we moved mardi.work from vanilla JS to Next.js
A practical look at why we migrated the mardi.work website to Next.js, with a focus on consistency, maintainability, and analytics.
We recently migrated the mardi.work website from plain HTML, vanilla JavaScript, and vanilla CSS to Next.js.
This was not a rewrite for the sake of rewriting. The previous site worked well. The decision was mainly about making the website easier to maintain as part of the wider set of products we build and run.
The main reason: consistency across projects
Most of the apps we design, build, and maintain already use a modern React and Next.js stack. Keeping the main mardi.work website on a completely different setup was becoming increasingly inefficient.
Even small updates required a context switch. Depending on the project, we had to move between different patterns, tooling, and development habits. Over time, that kind of fragmentation creates unnecessary overhead.
By moving the website to Next.js, we now have a more consistent technical foundation across our projects. That makes day-to-day work simpler and reduces maintenance friction.
A more practical stack for how we work
The migration was not driven by trends or by the idea that every site needs a framework.
In fact, the old site was simpler in some ways. But the bigger picture mattered more. Using the same core stack across multiple projects makes development more predictable, easier to maintain, and less mentally expensive.
Yes, it is more abstraction than the old site strictly needed, but for us the reduction in maintenance overhead made that tradeoff worthwhile.
Easier analytics integration
The second reason was analytics.
We wanted a cleaner way to track and understand how the website is being used, and we were already using a workflow built around Vercel. Moving the site to Next.js made it much easier to integrate Vercel Analytics in a way that felt native to the rest of our setup.
That means less custom handling, fewer mismatched tools, and a more straightforward path from deployment to measurement.
A small migration with a clear payoff
From the outside, this is not the most dramatic migration. The site does not suddenly become a different product because the stack changed.
But internally, it was the right move.
The new setup fits better with the rest of our work, simplifies ongoing maintenance, and gives us a cleaner foundation for future updates. That was the goal from the start.