Why using Nuxt.js?

When the old dashboard became a constraint

Our first dashboard used jQuery and vanilla JavaScript. It served the company well, but the cost of changing it increased as the product and team grew.

New engineers needed weeks to understand custom patterns. Adding modern libraries required extra integration work, and small changes often touched code that had no clear boundary. We were spending too much time working around the foundation.

How we evaluated the replacement

We compared React, Angular, Vue, and their meta-frameworks. The goal was not to pick the most popular option. We needed a framework the team could learn, migrate toward gradually, and operate over several years.

We first used Nuxt for the KiriminAja help site at help.kiriminaja.com. That project gave us a smaller place to test Vue, file-based routing, server rendering, modules, and deployment before touching the main dashboard.

Why Nuxt fit the team

Vue was easier to introduce

Vue's component model was close enough to our existing frontend work that engineers could become productive without learning several new abstractions at once.

We could choose the rendering mode

Nuxt supported server rendering, static generation, and client-side application flows in one framework. That mattered because our products did not all have the same delivery needs.

The project structure reduced custom decisions

File-based routing, auto-imports, and the module system removed conventions we had previously maintained ourselves. TypeScript support also gave the growing team better feedback while changing shared code.

The ecosystem covered common application work

Nuxt gave us established paths for authentication, state, data fetching, and deployment. We could spend less time designing framework infrastructure for each new project.

The migration took two years

We did not replace the main dashboard in one release. For almost two years, the team maintained the legacy application while moving product areas to Nuxt.

Running both systems was the hardest part. Every feature decision had to account for the old dashboard, the replacement, testing, and migration order. The staged approach was slower than a rewrite on paper, but it let us keep shipping while reducing the risk of a single cutover.

The first beta shipped in 2023. We launched the Nuxt dashboard to all users in September 2025.

What changed after the migration

The new foundation made it easier for incoming engineers to contribute and gave the team one shared set of frontend conventions. Nuxt now powers 80% of our new web frontend applications. We still use other frameworks when a project has different constraints, including React Router for our Shopify app.

The decision in hindsight

Nuxt was not perfect, and the migration was not cheap. We dealt with framework bugs, new patterns, and the operational cost of two applications.

The old jQuery foundation was not a mistake. It was the right system for an earlier stage of the company. Moving to Nuxt became necessary when maintaining that system started limiting the team more than it helped.