Let Clients Edit a Next.js Site Without a CMS

You can let clients edit a Next.js site without a CMS by keeping the editable text in files inside the repo (Markdown, MDX or JSON) and giving the client a safe way to change those files: a Git-based editor such as Decap, TinaCMS or Keystatic, GitHub's own web editor behind a pull request, or a chat tool that edits the repo with guardrails. Which one fits depends on how much the client edits and how much of the site's text still lives inside components.

The rest of this post walks through the groundwork that makes any of these work, then each option with its honest trade-offs.

Why "Without a CMS" Is a Reasonable Goal

Most agency Next.js sites are finished code. The homepage headline sits in app/page.tsx, the pricing table in a component, the opening hours in the footer. Wiring a headless CMS in later means modelling every piece of content, replacing hard-coded strings with fetched fields, adding preview and keeping a second system running. For a site with a blog or a product catalogue that work pays for itself. For a site where the client changes a phone number, a banner and a few sentences a month, it usually does not. We covered that trade-off in more depth in CMS Chat vs headless CMS.

The alternative is to treat the Git repository as the source of truth and make the parts clients touch easy to change safely.

Step Zero: Move Copy Out of Components

Whatever tool you pick, editing is easier when text lives in content files rather than deep inside JSX. Next.js supports this directly. The official Next.js MDX guide explains that Next.js "can support both local MDX content inside your application, as well as remote MDX files," and that .mdx files can act as pages or be imported into pages. Frontmatter is not supported by @next/mdx out of the box, so the guide points to packages such as gray-matter or remark-frontmatter if you need it.

A practical layout for a marketing site:

• content/pages/home.mdx for long-form text such as the about section
• content/site.json for short values: phone number, address, opening hours, social links
• content/blog/*.mdx for posts

Components then import or read these files instead of holding the strings. You do not have to move everything at once. Start with the five things the client asks you to change most often.

Option 1: A Git-Based Editor (Decap, TinaCMS, Keystatic)

Git-based editors give the client a form-style admin screen, but save every change as a file in your repository instead of a database.

• Decap CMS calls itself "an open source content management system for your Git workflow." Its docs say content "is stored in your Git repository alongside your code," and editors sign in through GitHub, GitLab or Bitbucket.
• TinaCMS describes itself as "an open-source, Git-backed headless content management system," storing content as Markdown, MDX and JSON in Git, with visual editing for React sites.
• Keystatic describes itself as "a tool that makes Markdown, JSON and YAML content in your codebase editable by humans," with a Next.js integration and a GitHub mode.

Works when: the content is already in files (Step Zero), there are repeating collections such as posts, team members or case studies, and the client is happy to learn an admin screen.

Trade-offs: you still write a schema or config that describes every editable field, and you maintain it when the design changes. Text that stays hard-coded in components is invisible to the editor. And the client now has a dashboard to learn, which is the thing many small business owners were hoping to avoid.

Option 2: GitHub's Web Editor Plus a Pull Request

If the client is comfortable enough with a browser, they can edit a content file directly on GitHub. The GitHub docs on editing files describe the flow: open the file, click the pencil icon, change the text, preview it, then commit to a new branch and open a pull request.

Pair it with branch protection on main so that pull request reviews and passing status checks are required before anything merges. Add a preview deployment per pull request and the client can see their change before you approve it.

Works when: the client is a technical-ish founder, edits are rare, and you want zero extra tooling.

Trade-offs: most clients find GitHub intimidating. They need to know which file holds which text, and a stray quote in a JSON file breaks the build. You end up reviewing every typo fix.

Option 3: Environment Variables or a Settings File for a Handful of Values

For a site where only three or four values ever change (a promo banner, a phone number, a booking link), a single site.json or a small set of build-time settings can be enough. The client sends the new value, you change one line, the site redeploys.

Works when: the list of editable things is tiny and stable.

Trade-offs: the client still depends on you for every change. This shortens your work, not their wait.

Option 4: Chat Editing on the Repository

The newest approach skips the admin screen. The client types the change in plain language ("change the Saturday hours to 9 to 2"), and an AI tool finds the right file in the repo, edits it and records the change as a Git commit or a pull request. Because it reads the code, it can also reach text that still lives inside TSX components, which form-based editors cannot see without a schema.

The risk is obvious: an AI with write access to a production repo can change things it should not. So the questions to ask any tool in this category are about limits, not features:

• Can you mark which parts of the site are editable and which are locked?
• What happens to a request that touches layout or code: is it guessed, or handed to a developer?
• Does every change land in Git, where you can review and revert it?
• Is there a warning before an edit changes a page title, H1 or meta description that brings in search traffic?

We wrote a longer guide to that last question and the rest of the guardrails in safe website editing for clients.

Works when: the site is finished custom code, edits are small and frequent, and the client will not learn a dashboard.

Trade-offs: it is a newer category, so judge each tool on its guardrails. It is not the right fit if the client needs to rebuild pages or design new sections; that is a job for a page builder or for you.

How CMS Chat Handles This

CMS Chat is a chat editor of the Option 4 kind. You install its GitHub App on the client's repository; it detects that the site is Next.js and scans the repo to map editable zones such as text, images, links and prices in TSX, MDX, Markdown, HTML and JSON files. There is no plugin and no content migration, so Step Zero is helpful but not required.

Each zone gets a guardrail: editable, warn, escalate or locked. Routine edits are committed; risky ones become a GitHub pull request for the developer, and layout or code changes are never guessed. If you connect Google Search Console, it warns before an edit touches a title, H1 or meta description that ranks. Agencies can give each client their own portal with invites and an activity history, and developers can also make edits from Claude, ChatGPT, Claude Code or Cursor through the MCP endpoint.

CMS Chat is in beta. See the features, or join the beta if you want to try it on a client site.

Which Option to Pick

1. A blog or many repeating items, and a client who likes forms: a Git-based editor such as Decap, TinaCMS or Keystatic.
2. A technical founder who edits rarely: GitHub's web editor with branch protection and preview deployments.
3. Three values that change twice a year: a settings file, and you make the change.
4. A finished site where text is spread across components and the client wants to type what they need: chat editing on the repo, with guardrails you control.

Whichever you choose, keep the repository as the single source of truth, require review for anything beyond copy, and give the client a preview before it goes live. Those three rules matter more than the tool.