Hand off a Next.js site to a non-technical client

The site looks great. The typography is dialed in, the layout shifts are gone, the Lighthouse score is green. You ship it, send the invoice, and feel good.

Then, three days later, the client emails: "Can you change the homepage headline? And the phone number in the footer is wrong."

So you find the string in a .tsx file, change it, commit, wait for the deploy, and reply. That edit took four minutes and the email thread took twenty. Now multiply it by every typo, every new bio, every seasonal promo, for the life of the site.

That is the handoff problem. The site works. The handoff doesn't.

A custom Next.js site you can't hand off isn't finished. It's a subscription to you. The fix is deciding, before you build, which parts the client owns and how they reach them.

The short answer

If a non-technical person needs to change the words, you can't hardcode the words. You need a content layer they can reach without you and without Git.

Your realistic options are a headless CMS, a Git-based CMS, or an integrated CMS that ships with its own admin. Each trades off differently on who owns the code, how editing feels, and what it costs per month. Pick based on how often the client edits, how visual their edits are, and whether you want to keep owning the codebase.

The tool matters less than the handoff discipline: define what's editable, write a one-page guide, set roles, and plan for images and forms before you leave.

Why hardcoded content fails at handoff

Hardcoding is fine while you build. It's the fastest way to get a layout on screen, and for a true brochure site that genuinely never changes, it can be the right answer.

But "never changes" is rarer than clients think. A phone number, a price, a holiday banner, a new staff photo: these come up. And every one routes back through you, because the content lives in code that only a developer can touch and only a deploy can publish.

So unless the content is genuinely frozen, the question isn't whether to add a content layer. It's which one.

Option 1: A headless CMS (Sanity, Contentful)

A headless CMS stores content in someone else's system and serves it to your Next.js app over an API. You model the content, the client edits it in a hosted dashboard, and your front end fetches it at build or request time.

Sanity and Contentful are the well-known choices, and they're genuinely good. Sanity's editing experience is excellent, its content modeling is flexible, and its real-time collaboration is better than most. Contentful is mature and a safe pick for larger teams with governance needs.

The tradeoffs are real, though.

It's API-only. The dashboard edits structured fields, but it has no idea what your page looks like. The client types a headline into a box and hopes it fits. No visual, on-page editing out of the box.
Billing scales with use. Free tiers are generous to start, then you hit per-seat or per-API-request pricing as the client adds editors or traffic grows. For a small business site that's an ongoing cost that didn't exist before.
Content lives off-site. You own your code, but the words and images sit in a vendor's database. Export paths exist, but it's not the same as owning everything.

Headless suits a content-heavy site with a real editorial team, multiple front ends sharing content, or a client who's fine editing structured fields without seeing the page.

Option 2: A Git-based CMS (Tina, Decap)

A Git-based CMS keeps content in your repository as Markdown or JSON. The client edits through a web UI, and their changes become commits. Your existing deploy pipeline takes it from there.

TinaCMS and Decap CMS (formerly Netlify CMS) are the common picks. Tina adds visual editing on top of Git, a genuine step up. Decap is free and open source.

The appeal is obvious for developers: content lives in Git, so it's versioned, diffable, and yours. No separate database, no vendor lock on the content. The tradeoffs land on the client side.

Every edit is a commit, so every edit triggers a build and deploy. Publishing isn't instant; it's a pipeline. For a client used to "save and it's live," that lag confuses.
The model leaks Git concepts. Branches, pull requests, build status: even when hidden well, the mental model underneath is version control, and it surfaces at the worst times.
Some of these tools have had bumpy maintenance and shifting business models. Check current activity before committing a client to one.

Git-based CMS suits a developer-led project where the client edits occasionally, the content is mostly text and Markdown, and you want everything to live in one repo.

Option 3: An integrated CMS with a visual editor

The third path is a CMS that ships as part of the app: its own admin panel, database, and editing UI, all running in your Next.js deployment. The client logs in, edits on something close to the real page, and publishes.

This is the path that most directly solves handoff: the client gets one place to log in and a visual editor that matches what visitors see. No API-only abstraction, no Git step between save and live.

Slim Minima is one open-source option here, and since this is its blog I'll be specific about how it's built and where it falls short. It's a Next.js 16 app with an admin panel at /admin, a block-based visual editor, two roles (admin and editor), and a Postgres database you own. The developer keeps owning the code in Git; the client only ever touches the admin. I wrote more about that division of labor in building a client-ready website with Slim Minima, and the reasoning behind it in why I built Slim Minima.

The honest tradeoff for any integrated CMS, this one included, is extensibility. Slim Minima has no plugin marketplace. You extend it by writing TypeScript and React, not by clicking install. For a developer that's often fine, even preferable, because there's no plugin attack surface to babysit. But if you wanted a one-click app store, this isn't that.

It's also made for content and marketing sites, not real-time apps or write-heavy workloads.

How the three options compare

The same site can be handed off with any of these. They differ on who owns what and how editing feels.

	Headless (Sanity, Contentful)	Git-based (Tina, Decap)	Integrated (e.g. Slim Minima)
Content lives in	Vendor's cloud	Your Git repo	Your own database
Editing model	Structured fields, API-only	Web UI that writes commits	Visual editor on the page
Publish speed	Fast	Waits for a build	Instant
Typical cost driver	Seats / API requests	Mostly free	Hosting only
Best when	Editorial team, many front ends	Dev-led, occasional text edits	One client needs to self-serve visually

None of these is right for every project. A documentation site and a five-page local business site want different things.

Handoff steps that work with any tool

Whichever CMS you pick, the handoff itself is what makes the difference. These steps apply across all of them.

Define the editable regions before you build. Decide which parts the client owns (headlines, body copy, images, prices, team bios) and which stay in code (layout, navigation structure, design tokens). Build those editable parts as content, not as hardcoded strings. This decision is the whole game.
Write a one-page client guide. Not a manual. One page: how to log in, change a headline, swap an image, publish, and who to contact if something breaks. Screenshots help. Most "the site is broken" emails are really "I forgot how to do the thing."
Set roles and permissions. Don't hand over admin keys if the client only needs to edit posts. An editor role that can publish content but can't touch settings or users prevents most accidental damage. Match the role to what they actually do.
Plan for images. This is where handoffs quietly fail. If the client uploads a 6 MB phone photo into a hardcoded <Image>, your performance work evaporates. Use a media pipeline that compresses and serves from a CDN. Slim Minima routes uploads through the client's own Cloudinary account, which compresses and serves images without using your hosting bandwidth, but the principle holds either way: never let raw uploads hit the page.
Plan for forms. Clients ask for contact forms, and forms need somewhere to send submissions, spam protection, and a record even when email fails. Decide up front where submissions go, how you catch spam, and whether the client can read entries without you.
Set up scheduled publishing. Clients want to write a promo now and have it appear Monday. A CMS that supports a publish date saves you from flipping a switch on a Sunday night. Confirm go-live doesn't require a manual deploy on your end.

Do these six things and the client edits without you. That's the actual definition of a finished handoff.

What I'd skip

Not every site needs a CMS. For a one-page launch site, or a portfolio the owner happily edits in code, a content layer is overhead you'll both regret. Hardcode it, hand over the repo, and move on. The CMS conversation starts the moment a non-technical person needs to change words on a schedule you don't control.

Frequently asked questions

What is the best way to make a Next.js site editable by a non-technical client? Give them a content layer they can reach without code or Git: a headless CMS, a Git-based CMS, or an integrated CMS with its own admin panel. The right one depends on how often and how visually the client edits. The common rule is to never hardcode anything the client will need to change.

Can a client edit a Next.js site without touching code? Yes, if you build the changeable content as data rather than hardcoded strings and connect it to a CMS. The client edits in a dashboard or visual editor and publishes, while you keep owning the code. Without that layer, every edit routes back to you and a deploy.

Headless CMS or Git-based CMS for a client handoff? Headless (Sanity, Contentful) gives a polished editor but is API-only and bills per seat or request as you grow. Git-based (Tina, Decap) keeps content in your repo and is often free, but every edit triggers a build and the model leaks Git concepts. Pick headless for editorial teams, Git-based for dev-led sites with occasional text edits.

How do I stop a client from breaking the site after handoff? Use roles so editors can change content but not settings, users, or layout. Write a one-page guide covering login, editing, and publishing. Build only the intended regions as editable and keep structure in code. Most damage comes from giving clients more access than they need.

Do I lose ownership of my Next.js code when I add a CMS? Not necessarily. With a Git-based or self-hosted integrated CMS, the code stays in your repository and the database is yours. With a hosted headless CMS, your code stays yours but the content sits in the vendor's cloud. Check the export and licensing terms before you commit a client to any option.

My verdict

If you build custom Next.js sites for clients, decide the content layer before you write the first component, not after the invoice.

For an editorial team or a multi-front-end setup, a headless CMS like Sanity earns its cost. For a dev-led site with light, occasional edits, a Git-based CMS like Tina keeps everything in your repo. For a single client who needs to self-serve and see what they're editing, an integrated CMS with a visual editor removes the most handoff friction, at the cost of extending by code rather than plugins.

Whatever you pick, the handoff is the work: define what's editable, write the one-page guide, set roles, plan for images and forms. Get that right and your job ends at ship, where it was supposed to end.

How to hand off a Next.js site to a non-technical client