Next.js or plain React — what decides it?

Plain React is enough when the application sits behind a login and nobody needs to find it. As soon as pages are public or have to load fast, Next.js takes over the rendering. This page is Next.js with Server Components.

How fast was the first working version there?

Two to four weeks — whether the end result was one feature or a platform. The first version was deliberately small: one screen with real records, checkable rather than believable.

Can an application that has grown be migrated instead of rebuilt?

Usually yes, and usually it is the cheaper arithmetic. The migration runs route by route to Next.js — the old application stays live until the new one can do more than it.

What do Server Components do for load time?

They move work from the browser to the server: less JavaScript in the bundle, less time to the first useful picture. Client code goes only where interaction forces it.

What was left behind at the end — just the code, or documentation too?

The repository, the deployment description and the decisions that are not visible in the code. The team had to be able to keep building without me — that was the test, not the line count.

Home Expertise01 · Full-stack development

Full-stack development

React and Next.js frontends with Server Components, backends with TypeScript, Python and PostgreSQL. This page shows what it fails on, how I built it, and what you can check it against.

One take, no cut: input, validation, response, record.Video · 21:9

Area: 01 of 04
Stack: 11 technologies
Reference: AI profile generator

AI-generated

The data model first, the interface second. In that order, every time.21:9

The situation: growth at the edges

Applications grow at the edges. First one feature is added, then a second frontend, then an interface nobody can keep track of. At some point the question is no longer what should be built, but who still knows why it's built this way.

Architecture sketch in three handwritings — Three people drew on it. None of them is still on the project.16:9

Every addition was right on its own. Together they make a map nobody carries in their head any more.Video · 21:9

Way of working

I start with the process, not the tool. Data model first, then the interfaces, then the surface. Server Components as the default, client code only where interaction forces it — that keeps the JavaScript budget small and the load time low.

EvidenceBefore and after2 exhibits

Photo: the data model on paper, before the first line of code

AI-generated

The reference project for this area

A capability with no project behind it is a list of technologies. This is the project — with the number it produced, and the case study where you can check it.

Recruiting · AI

3 min

per proposal · was 45

Exposés that write themselves in three minutes

Applications and CVs become a finished candidate profile — Claude writes the copy, the pipeline sets the document.

Next.js TypeScript PostgreSQL pgvector RAG Claude / GPT / Gemini AWS (S3, Lambda) Docker

Screenshot: form and preview side by side — The same case from inside: the interface16:9

Screenshot: the same view on a phone — The same case from outside: the same thing on a phone16:9

All reference projects

What I worked on

Four kinds of work, each with the one picture that makes it checkable. Numbered so they can be pointed at — not because one follows another: each stands on its own.

01
Customer portals and internal platforms
02
Replacing bought-in SaaS tools with your own build
03
Migrating existing applications to Next.js and SSR/RSC
04
Performance and UX rework of systems that have grown over time

The stack: Next.js, React, PostgreSQL

After the situation and the way of working, nobody is still asking what is installed — they are asking whether any of it is real. The line stays; two frames below it answer.

Next.js React TypeScript Tailwind CSS SSR / RSC Node Python PostgreSQL Prisma REST-APIs WebSocket

In use

Repeatable

Screenshot · the Prisma schema, typed down to the query

Scale

The work ran from a well-defined feature over four weeks to a platform over several months. Either way, a first working version was there after two to four weeks.

Small case

Feature · One bounded slice — A single screen that did not exist on Monday and was in production on Friday.16:9

Large case

Not one screen, but the number of parts that have to keep agreeing with each other.Video · 16:9

Common questions

Five questions that keep coming up about this area — answered from the projects they came up in.

Next.js or plain React — what decides it?: Plain React is enough when the application sits behind a login and nobody needs to find it. As soon as pages are public or have to load fast, Next.js takes over the rendering. This page is Next.js with Server Components.
How fast was the first working version there?: Two to four weeks — whether the end result was one feature or a platform. The first version was deliberately small: one screen with real records, checkable rather than believable.
Can an application that has grown be migrated instead of rebuilt?: Usually yes, and usually it is the cheaper arithmetic. The migration runs route by route to Next.js — the old application stays live until the new one can do more than it.
What do Server Components do for load time?: They move work from the browser to the server: less JavaScript in the bundle, less time to the first useful picture. Client code goes only where interaction forces it.
What was left behind at the end — just the code, or documentation too?: The repository, the deployment description and the decisions that are not visible in the code. The team had to be able to keep building without me — that was the test, not the line count.