Victor Malai is the Team Lead Developer at PBX.IM, with over 13 years of experience in web development and deep expertise in React, Vue.js, TypeScript, and Laravel. Known for his curiosity and passion for clean architecture, he stays ahead of the latest tech trends while guiding his team in building scalable, well-structured solutions.
At PBX.IM, our engineers focus on keeping the platform performant, secure, and scalable. At the end of 2025, we hit deployment constraints that led us to rethink our frontend build architecture. In PBX 2.0.0, we migrated from Next.js to a Vite-built React SPA deployed as static assets.
This post walks through why we made the switch, what changed, and what the new architecture enables.
TL;DR: We replaced Next.js with Vite + React to produce pure static builds with no Node runtime dependency. Same UI, same features: simpler deployment model.
Our frontend was a Next.js app, but we weren't using it like one. The entire UI ran as a client-side SPA — routing was handled by React Router, data came from our Laravel backend and SIP APIs, and we'd disabled SSR entirely. Our catch-all route looked like this:
// frontend/src/app/[[...]]/page.tsx
"use client";
import dynamic from "next/dynamic";
const AppLayout = dynamic(() => import("@/layouts/app-layout"), {
ssr: false,
loading: () => <div style={{ display: "none" }} />,
});
export default function CatchAllPage() {
return <AppLayout />;
}A single catch-all page with SSR explicitly disabled. We were paying for Next.js's server runtime, file-system router, and build complexity while opting out of every feature that justified that cost.
The specific pain points:
Vite's architecture — build static assets, serve them however you want — matched what we were already doing, without the workarounds.
The migration touched 723 files but was deliberately narrow in scope: replace the build pipeline and runtime, keep everything else. Components, business logic, hooks, stores, and queries stayed intact.
The core change was swapping Next.js's build pipeline for Vite:
// frontend/vite.config.ts
export default defineConfig(({ mode }) => ({
plugins: [react(), svgr({ include: "**/*.svg" })],
resolve: {
alias: { "@": path.resolve(__dirname, "./src") },
},
build: {
sourcemap: mode !== "production",
},
server: {
port: 3000,
host: true,
},
}));
React plugin, SVG support, path aliases, and environment-aware sourcemaps. Every build produces a `dist/` directory of static files — no server process required.
Next's app/ directory and catch-all route were replaced with a standard SPA entry point:
<!-- frontend/index.html -->
<body>
<div id="root"></div>
<script type="module" src="/src/main.tsx"></script>
</body>main.tsx mounts the React app with React Router handling all navigation — the same routing setup we already had, minus the Next.js wrapper.
We dropped everything Next.js-specific:
That last point is worth emphasizing. We had ~200 lines of API proxy code (api-utils.ts, axios-instance.ts, qs-utils.ts) running on Next's server to forward requests to our Backend API. Removing the Node runtime meant the frontend talks directly to backend APIs, eliminating an unnecessary hop.
We moved from eslint-config-next to a framework-agnostic ESLint setup with @typescript-eslint, eslint-plugin-react, and eslint-plugin-react-hooks. Same linting rigor, no framework coupling.
This was not a rewrite. The migration preserved:
The diff is large by file count because hundreds of source files had minor cleanup (removing unused Next.js imports like "use client" directives), but the functional changes were confined to the build and configuration layer.
Environment-agnostic deployment. The dist/ output is a set of static files. Upload to S3, serve from a CDN, drop behind Nginx, or bundle with a Laravel deployment — no Node process to manage, no runtime to configure per environment.
Faster development cycles. Vite's dev server and HMR provide noticeably faster feedback loops than our previous Next.js setup with Turbopack.
Simpler CI/CD. Build artifacts are static files. Our deployment pipeline no longer needs to provision or manage a Node runtime in target environments.
This migration went the opposite direction from what's trendy. Many teams move from Vite to Next.js to adopt SSR, server components, or API routes. If your application benefits from those features, Next.js remains a strong choice.
Our requirements pointed the other way. We needed a static SPA that powers VoIP deployments across cloud, hybrid, and on-premise environments. Vite's build-static-assets-first architecture was the better fit. The right tool depends on what your deployment model actually requires.
