Rebuilding CRG Direct: From Next.js to SvelteKit — 90% Less RAM, Two Carbon Grades Higher

Why Rebuild a Production Site From Scratch?

CRG Direct is an MCS-certified renewable energy company based in Hampshire, specialising in solar panels, heat pumps, battery storage, and EV chargers across the south of England. Their website isn’t a brochure — it’s a full-stack platform with a CRM, admin panel, customer portal, and lead management system.

The site was originally built on Next.js with React. It worked. But three problems were compounding:

Build times had hit 8.5 minutes — every deployment was a coffee break
React and Next.js had been shipping critical vulnerabilities at an uncomfortable rate
The carbon score was mediocre — not where a renewable energy company’s website should be

We’d already rebuilt the Quantum Encoding website in SvelteKit and seen dramatic improvements. CRG Direct was the next candidate.

The Scale of the Rebuild

This wasn’t a simple marketing site migration. CRG Direct runs:

30+ public routes — services, locations, product pages, blog, legal pages
27+ admin panel sections — full CRM with lead management, customer records, job tracking
Real-time dashboards — analytics, pipeline views, activity feeds
Document management — quotes, invoices, certificates, file uploads
Authentication and role-based access — admin, staff, and customer portals

The entire stack was rebuilt from the ground up in SvelteKit 5 with TypeScript and Tailwind CSS 4.

Build Time: 8.5 Minutes to 2 Minutes

The headline number that drove the migration:

Metric	Next.js (React)	SvelteKit	Improvement
CI/CD build + deploy	8.5 min	2 min – 2 min 20s	75% faster
Local production build	~52s	~6s	89% faster
Hot module reload	~2s	Under 100ms	Imperceptible

On CI/CD, SvelteKit builds in around 2 minutes including deployment. Locally, the production build completes in about 6 seconds — compared to nearly a minute for Next.js compiling and statically generating 800+ pages. During development, hot reloads are effectively instant.

The 8.5-minute Next.js CI/CD builds weren’t just slow. They were expensive. Every CI/CD minute costs compute. Multiply that across dozens of deployments per week during active development, and those minutes translate directly into money and lost momentum.

RAM: From 1.6GB to 170MB

The Next.js version required a 2GB build machine and consumed around 1.6GB of RAM at runtime. That’s 80% of the machine’s total memory just to serve the application.

The SvelteKit version runs on a 500MB machine and uses approximately 170MB of RAM at runtime — about 34% of a machine a quarter the size.

Metric	Next.js (React)	SvelteKit	Reduction
Build machine	2GB	500MB	75% smaller
Runtime RAM usage	~1.6GB	~170MB	89% less

That’s not a marginal improvement. The SvelteKit version uses roughly one-tenth the memory of its React predecessor. The build machine went from 2GB to 500MB, and the application still only uses a third of that.

This translates directly into infrastructure costs. Smaller instances are cheaper. When your application fits comfortably in 170MB, you’re paying for a fraction of the compute. The savings compound with every hour the server runs.

Carbon Score: Two Grades Higher Overnight

Here’s the number that matters most for a renewable energy company:

The carbon rating improved by two full grades — just from changing the framework.

No content changes. No image optimisation pass. No lazy-loading audit. The same site, the same content, the same images — rebuilt in SvelteKit instead of React. Two grades better.

Why the Framework Matters This Much

React ships a runtime to every visitor. That runtime has to be downloaded, parsed, and executed — even on pages where most of the content is static. Every kilobyte of JavaScript has a carbon cost:

Network transfer — energy consumed by CDNs, routers, and the client’s radio/WiFi
CPU parsing — the browser has to parse and compile the JavaScript before it can do anything
Execution — the virtual DOM reconciliation runs on every state change, burning cycles

SvelteKit compiles away the framework. What ships to the browser is the minimal JavaScript needed for interactivity — nothing more. For a site like CRG Direct, where most pages are informational, the difference is enormous.

A renewable energy company’s website should practice what it preaches. Two carbon grades from a framework change alone is the kind of free win that’s hard to argue against.

Security: 1,656 Dependencies Down to 585

This migration happened against a backdrop of serious security incidents in the React and Next.js ecosystem. In 2025 alone:

CVE-2025-29927 (March 2025, CVSS 9.1) — a Next.js middleware authorization bypass that allowed attackers to skip authentication entirely by sending a crafted x-middleware-subrequest header. Every Next.js application using middleware for auth was vulnerable by default.
CVE-2025-55182 “React2Shell” (December 2025, CVSS 10.0) — an insecure deserialization flaw in React Server Components that allowed unauthenticated remote code execution. A default create-next-app production build was exploitable with no code changes. Near-100% reliability. Attackers were observed stealing cloud credentials and deploying cryptominers in the wild.
CVE-2025-55183 (December 2025, CVSS 5.3) — source code exposure in React Server Components.
CVE-2025-55184 and CVE-2025-67779 (December 2025, CVSS 7.5) — denial-of-service attacks against React Server Components.

That’s a CVSS 10.0 RCE and a CVSS 9.1 auth bypass in the same year, both affecting default configurations. Palo Alto Networks identified over 968,000 exposed React and Next.js instances in their telemetry.

The Dependency Problem

Beyond the framework-level CVEs, there’s the dependency tree itself. The CRG Direct Next.js project carried 1,656 transitive dependencies. The SvelteKit rebuild: 585.

Metric	Next.js (React)	SvelteKit	Reduction
Total dependencies	1,656	585	65% fewer

Every dependency is a package that needs to be kept up to date, a potential target for supply chain attacks, and a surface area for future CVEs. Cutting the dependency count by nearly two-thirds isn’t a minor improvement — it’s a fundamentally smaller attack surface.

For a site that handles customer data, lead information, and business-critical CRM operations, reducing exposure isn’t optional. It’s responsible engineering.

Developer Experience: The Underrated Factor

The numbers — build times, RAM, carbon scores — are the measurable wins. But the developer experience improvement is what makes the rebuild sustainable long-term.

Svelte 5 Runes

Svelte 5 introduced runes ($state(), $derived(), $effect()), which replace the older reactive declarations. The result is reactive state management that reads like plain JavaScript:

let count = $state(0);
let doubled = $derived(count * 2);

No useState hooks. No dependency arrays to get wrong. No stale closure bugs. The compiler handles reactivity at build time, so the mental model is simpler and the failure modes are fewer.

Tailwind CSS 4

The rebuild also moved to Tailwind CSS 4 with its new @theme configuration block. Combined with SvelteKit’s scoped styles, this means:

Zero runtime CSS-in-JS overhead
Design tokens defined once, used everywhere
Component-scoped styles that don’t leak or conflict

File-Based Routing That Just Works

SvelteKit’s file-based routing handles the full spectrum — from simple static pages to complex nested layouts with authentication guards. The 30+ public routes and 27+ admin sections all slot naturally into the src/routes/ directory without any routing configuration files.

The Migration Approach: 6 Days With AI-Assisted Development

We didn’t attempt a gradual migration. React and Svelte have fundamentally different component models — trying to run them side by side creates more complexity than it solves.

Instead, we rebuilt from the ground up. The entire migration — 30+ public routes, 27+ admin sections, full CRM, authentication, document management — was completed in 6 days. That timeline was only possible because of Claude Code and a parallel agent workflow.

How the Rebuild Actually Worked

The rebuild was driven by multiple AI agents working in parallel from a shared schema. Each agent had a clearly defined scope — one handling public routes, another on the admin panel, another on the data layer — all working against the same type definitions, the same component library, and the same architectural rules.

This wasn’t vibe coding. Every agent was:

Building against a strict schema — shared TypeScript types and component interfaces that every agent had to conform to
Continuously validating the build — running npm run build after each change to catch type errors and regressions immediately
Following security requirements — no shortcuts on authentication, input validation, or role-based access. Every API route was properly guarded, every form input sanitised
Working to a defined architecture — file-based routing conventions, consistent data patterns, shared design tokens

The human role was direction, architecture, and quality control. Define the schema. Set the constraints. Review the output. The agents handled the volume — converting hundreds of components, routes, and API endpoints in parallel.

This is what we mean by AI-assisted development rather than vibe coding. Vibe coding is asking an AI to “build me an app” and hoping for the best. AI-assisted development is engineering a system where AI agents execute at scale within strict guardrails, with a human architect maintaining oversight of every architectural decision.

Data layer and schema first — defined all TypeScript types, database interactions, and API contracts
Shared components — rebuilt the design system as Svelte components with Tailwind CSS 4
Parallel route migration — agents worked simultaneously across public routes and admin sections
Continuous integration — every change was validated against the build, types, and security requirements
Human review and deployment — final verification of every route, form, and interaction

Six days for a full-stack rebuild of a production platform. SvelteKit’s simpler mental model meant less code per feature, and Claude Code’s parallel execution meant the volume of work didn’t bottleneck on a single developer. When you combine a better framework with a better workflow, the results compound.

Results Summary

Metric	Next.js (React)	SvelteKit	Change
CI/CD build time	8.5 min	2 – 2:20 min	-75%
Local build	~52s	~6s	-89%
Runtime RAM	~1.6GB	~170MB	-89%
Build machine	2GB	500MB	-75%
Carbon score	—	+2 grades	Framework change alone
Bundle size	Large (React runtime)	Minimal (compiled)	Significantly smaller
Dependencies	1,656	585	-65%
Rebuild time	—	6 days	Full ground-up rewrite

What This Means

CRG Direct is a real business serving real customers across Hampshire and the south of England. This wasn’t an experiment or a side project — it was a production rebuild of a platform that handles leads, customers, documents, and daily business operations.

The results confirm what we found with the Quantum Encoding migration: SvelteKit delivers measurably better performance, lower resource consumption, and a smaller environmental footprint. For CRG Direct specifically — a company in the business of renewable energy — having a website that’s genuinely more sustainable isn’t just a nice metric. It’s alignment between what they sell and how they operate.

The framework you choose matters. It affects your build times, your hosting costs, your security posture, your carbon footprint, and your team’s ability to ship quickly. For us, after two full-scale migrations, the choice is clear.