Next.js → Vite Migration
Removed the SSR runtime from applications that didn't need it, cutting cloud cost and 80% of deploy time.
- My role
- Technical lead of the migration
- Context
- SBSistemas · Smarten Venture Builder
- Category
- Performance & DevOps
I led the migration of Next.js applications to React with Vite, eliminating a rendering server that brought no benefit to authenticated products and cutting infrastructure costs along with delivery time.
Results
- −80%
- deploy time Product delivery dropped from 15 to 3 minutes
- −1
- server in production SSR runtime eliminated, with a direct cloud cost reduction
- 0
- downtime windows Incremental migration, with the product live the whole time
The problem
The products were closed systems behind a login: all the content is private, nothing is indexed by search engines, and there was no SEO or public first-load benefit to extract from SSR. Even so, we paid the framework's full price — a Node server running in production, recurring cloud cost, slow builds and a layer of complexity that showed up in every hydration bug. Deploys took 15 minutes.
The solution
I led the migration to a React SPA bundled with Vite. The decision came from the product's actual usage profile, not a tooling preference: with no need for server rendering, the runtime stops being an advantage and becomes pure cost. The migration was done incrementally, screen by screen, keeping the product live throughout the whole process.
Key challenges
-
Replacing Next's file-based routing with an explicit router, while preserving every URL customers were already using.
-
Migrating without freezing the roadmap: the application kept shipping new features while its foundation was being swapped underneath.
-
Reproducing what the framework delivered for free — route-based code splitting, asset optimization and environment variables — explicitly and auditably.
-
Convincing the team with data instead of opinion, measuring build time, bundle size and infrastructure cost before and after.
Technologies used
- React
- Vite
- TypeScript
- Next.js
- Zustand
- TanStack Query
- Docker
- GitLab CI/CD
The reasoning behind the migration
The question driving the project wasn’t “which framework is better,” but “what does this specific product gain from server rendering.” For a fully authenticated application, the honest answer was: nothing that justified the cost.
Documenting that with numbers — build time, bundle size, monthly cloud cost — is what turned a technical preference into a defensible engineering decision.
Related projects
makley.com
This portfolio — Astro, TypeScript and layered architecture, with virtually zero client-side JavaScript.
0 KB of UI framework
- Astro
- TypeScript
- Modern CSS
- Atomic Design
- DDD
- +2