Why I rebuilt my portfolio on Payload and Next.js
A self-funded rebuild is a rare chance to eat your own dog food. Here is why I chose Payload 3 and Next.js for my own site, and what it taught me about the stack I recommend to clients.
Every freelancer reaches the cobbler's-children moment eventually: a portfolio full of other people's sites and a homepage held together with a WordPress theme from 2019. Mine had served me well, but it had become a liability — slow to edit, awkward to extend, and increasingly out of step with the work I actually do.
So I rebuilt it from scratch. The brief was simple: a site that reflects how I build today, that I can edit without fighting the CMS: A content management system — software that lets you create, edit and organise the words, images and other content on a website without writing code., and that loads fast on a phone in a pub. Here is why I landed on Payload and Next.js, and the trade-offs worth knowing about.
Why Payload, not WordPress
I build a lot of WordPress, and I still think it is the right call for a huge number of clients. But for a content-driven marketing site where I want total control over the schema, Payload is a different league. I define collections and globals as code, version them in git: A version control system that tracks changes to code over time, making it possible to undo mistakes, experiment safely, and collaborate without overwriting each other’s work., and get a typed API: An application programming interface — a defined way for two pieces of software to talk to each other and exchange data. for free. There is no "find the right plugin" tax, and no bending a post type into shapes it was never meant to hold.
The clincher is the editing experience. Payload 3 runs inside Next.js, so my admin panel and my site share one process, one deploy, and one set of types. Editors get a clean, modern UI; I get a schema I actually understand.
Why Next.js, and the App Router
Server Components: React Server Components — a way of rendering parts of a web page on the server so they ship little or no JavaScript to the browser, keeping pages fast. changed the calculus. Most of a marketing site is just "read some data and render HTML" — exactly what RSC: React Server Components — a way of rendering parts of a web page on the server so they ship little or no JavaScript to the browser, keeping pages fast. is good at. The case-study pages on this site fetch a project and its related media on the server, stream in as they resolve, and ship almost no JavaScript to the browser. The bits that do need interactivity — a theme toggle, a scroll-driven video, a multi-step form — are small client islands.
Incremental static regeneration: Incremental Static Regeneration — a Next.js feature that serves a cached, pre-built page and quietly rebuilds it in the background, so updates appear without re-building the whole site. means published pages are cached and revalidated every minute, so edits go live quickly without rebuilding the world. For a solo operation with no DevOps team, that is hard to beat.
What I would do differently
I would wire up draft preview earlier. Drafts are easy to enable but pointless if editors cannot see them on the frontend — a lesson I learned the slightly annoying way. I would also design the content model around blocks sooner, rather than bolting sections in once the copy was written.
But the core decision — Payload for the content layer, Next.js for the front-end, everything typed end to end — I would make again in a heartbeat. It is the stack I now recommend to most clients, and it is nice to finally be able to point at my own site as proof.
