We rebuilt our entire platform from scratch on Next.js 16 with React 19, TypeScript, and App Router. Here's why, and what we gained.
en
no
frNatasun has always been about pushing boundaries. We were one of the early adopters of Next.js years ago, and we've been on a journey ever since — from WordPress to Laravel, from Pages Router to App Router, and now to Next.js 16.
This isn't just an upgrade. It's a complete rebuild. Every file, every component, every line of code — rewritten from scratch.
Here's why we did it, what changed, and why we believe it was the right call.
Our previous stack wasn't bad. It was Next.js 13 with Pages Router, MUI v5, Redux for state management, and JavaScript everywhere. It worked. But it had grown into something heavy.
State lived in 20+ Redux slices. Our authentication was stitched together from Auth0, Cognito, and Firebase — three different systems that barely talked to each other. We had JavaScript files throughout the codebase with no type safety. Server-side rendering was slow because everything went through axios HTTP calls to our own API before reaching the database.
The result? Slow page loads, a bloated bundle, and a codebase that was painful to work with. Every new feature felt like walking through mud.
We knew we could do better.
Next.js 16 with the App Router gave us something we'd been craving: Server Components.
With Server Components, most of our pages render on the server — not in the browser. That means smaller JavaScript bundles, faster first paints, and better SEO out of the box. No more client-side waterfalls. No more waiting for 20 Redux slices to hydrate before the page looks right.
Server Actions changed how we handle mutations. Instead of creating API routes and calling them with axios, we call functions directly. The framework handles the rest — serialization, error handling, revalidation.
And streaming? Our pages now load progressively. Users see content as it arrives, not all at once after everything finishes loading.
We rewrote every single file from JavaScript to TypeScript with strict mode enabled. No any types. No escape hatches.
This might sound like a lot of work — and it was — but the payoff has been immediate. We catch bugs at compile time now, not in production. Our IDE knows exactly what every function returns, what every API response looks like, and what every component expects as props.
For a platform as complex as Natasun — with a marketplace, chat system, blog CMS, project portfolios, and job board — type safety isn't a luxury. It's a necessity.
One of the biggest architectural changes was how we fetch data. Our old stack used axios to call our own API routes, which then queried the database. That's an extra network hop for every single data request.
Now, Server Components query the database directly through Prisma. No axios. No API routes in between. Just a straight line from component to database.
Prisma 6 gave us better performance, improved type safety, and a schema that actually reflects our data model clearly. With 30+ models — users, posts, products, orders, invoices, projects, jobs, comments, and more — having a well-typed ORM is critical.
Our old auth setup was a mess. Auth0 was configured. Cognito was configured. Firebase was configured. Three providers, three different patterns, three sets of bugs.
We replaced all of it with Auth.js v5 — a single, clean auth system that supports Google, GitHub, X (Twitter), LinkedIn, and email/password. It uses Prisma for session storage, JWT for tokens, and Cloudflare Turnstile for CAPTCHA.
Account linking works seamlessly now. A user can sign up with Google, connect their GitHub, and later log in with either one. The system just figures it out.
We didn't just rebuild existing features — we added entirely new ones. The biggest addition is our digital marketplace.
Sellers can list products with images, categories, tags, and pricing. Buyers can browse, add to cart, and checkout with PayPal, credit cards, or USDT crypto. Orders are tracked with full status workflows. Invoices are generated automatically. Reviews and ratings help buyers make decisions.
All of this runs on the same Prisma + Next.js stack. No third-party e-commerce platform. No Shopify embeds. Our marketplace, our code, our rules.
Natasun serves a global audience. We support English, Norwegian, and French — with more languages coming.
Every piece of content is stored as a JSON object with language keys. URLs are prefixed with the locale (/no/blog, /fr/about-us). Search engines index each language separately. And our i18n system handles everything from UI translations to date formatting to currency display.
This wasn't easy to build, but it was essential. Our users shouldn't have to speak English to use our platform.
Every public page on Natasun now generates comprehensive structured data. We're talking Schema.org markup for blog posts, job listings, products, projects, and organization data.
OpenGraph and Twitter Card meta tags are generated for every page. Hreflang alternate links tell search engines about all language versions. Dynamic sitemaps and RSS feeds keep search engines updated.
This isn't SEO as an afterthought. It's SEO baked into the architecture.
Here's a quick look at what changed:
Each change was deliberate. We didn't swap libraries for fun — we chose tools that are faster, more maintainable, and better suited to our needs.
This rebuild is the foundation. We're now iterating fast on top of it.
Coming soon: digital download delivery, subscription plans, enhanced project collaboration tools, better analytics for members, and API improvements for third-party integrations.
We're building Natasun to be the platform where digital creators, developers, and artists actually want to work. And with Next.js 16, we finally have the foundation to make that happen.
Have thoughts? Found a bug? Want to contribute? Reach out to us or open an issue on our GitHub.
