How to Give Marketers Access to a Static Site

You built a fast, modern website with Next.js or Astro. It's statically generated, version-controlled, and deploys on every push. The developer experience is excellent.

Then a marketer asks: "Can I change the hero headline?"

And now you have a problem.

The tension between developers and marketers

Developers love static sites for good reasons. The code lives in Git. Deployments are atomic. There's no database to manage, no CMS admin panel to maintain, and no API to rate-limit. The content lives as files (JSON, YAML, Markdown) right alongside the code.

Marketers hate this setup for equally good reasons. They can't change a headline without filing a Jira ticket, waiting for a developer to make a one-line edit, getting it through code review, and watching it deploy. A five-second text change takes three days.

This tension is real and it kills velocity. The marketer feels blocked. The developer feels like a human find-and-replace. Both are right.

Why traditional CMS breaks the workflow

The knee-jerk reaction is to add a CMS. "Let's put the content in Contentful / Sanity / Strapi, and the marketing team can self-serve."

This solves the marketer's problem but creates new ones for developers:

1. Content leaves Git

Your headings and CTAs are no longer version-controlled alongside the code that renders them. Instead, they live in a hosted database, fetched via API. You've split your source of truth.

2. Build-time complexity

Static generation now depends on an external API. Your build process needs API keys, handles rate limits, implements caching, and fails when the CMS is down. What was npm run build is now a fragile pipeline.

3. Schema management

Every content change now requires schema definitions in the CMS, migration scripts when you restructure, and type generation to keep your code in sync. The CMS that was supposed to save time is creating overhead.

4. Vendor lock-in

Your content is now in Contentful's data format, structured in their content model, accessible only through their API. Moving to a different system means a migration project.

5. Cost

CMS platforms are free to start and expensive to scale. Contentful's team plan starts at $300/month. Sanity's growth plan is $99/month. For editing text files.

The Git-based middle ground

There's a third option that most teams overlook: keep the content in Git, but add a visual editing layer on top.

The idea is simple. Your JSON, YAML, and Markdown files stay in the repository. A tool reads those files, presents them in a visual editor, and writes changes back as a Git commit or pull request.

The developer workflow doesn't change. Content is still in files, still version-controlled, still deployed the same way. But now the marketer has an interface to browse, edit, and preview content without touching the codebase.

How the PR workflow works

Here's what a content change looks like with this approach:

1. Marketer opens the editor. They see a visual interface showing the content files from the repo. No JSON, no YAML, just form fields with the current values.

2. Marketer makes changes. They update the hero headline, fix a typo in the footer, and change a CTA button label.

3. Marketer previews. A live preview shows exactly how the site will look with the changes applied. No guessing.

4. Changes become a pull request. The editor creates a branch, commits the file changes, and opens a GitHub PR. The marketer doesn't need to know what any of that means.

5. Developer reviews. The PR shows a clean diff: "Changed hero.title from X to Y in en.json." A quick review, approve, merge. The content deploys automatically.

This preserves everything developers care about (Git history, code review, atomic deploys) while giving marketers the self-service access they need.

What to look for in a Git-based CMS

Not all Git-based CMS tools are created equal. Here's what matters:

Zero config in your repo

Some tools require installing npm packages, adding config files, or restructuring your content directories. The best tools connect to your repo externally with no dependencies, no config files, and no coupling.

Works with existing file formats

You already have JSON, YAML, or Markdown files in a structure that works for your framework. A good tool should read those files as-is, not require you to rewrite them in a proprietary format.

Real-time preview

Marketers need to see their changes before committing. A preview that renders your actual site (not a generic template) is critical for confidence.

GitHub PR integration

Changes should go through your existing workflow. Branch, commit, PR, review, merge, deploy. No separate approval system, no sync process, no publish button that bypasses Git.

Access without training

If the editor requires a tutorial or documentation for non-technical users, it's too complicated. Marketers should be able to open it, find the content they want, change it, and save.

Setting this up for a Next.js site

Let's walk through a concrete example. Say you have a Next.js site with content in JSON files:

src/
  messages/
    en.json
    fr.json
    de.json
  app/
    page.tsx
    pricing/
      page.tsx

Your pages read from these JSON files using next-intl or a similar library:

import messages from "@/messages/en.json";

export default function HomePage() {
  return (
    <main>
      <h1>{messages.hero.title}</h1>
      <p>{messages.hero.subtitle}</p>
      <button>{messages.hero.cta}</button>
    </main>
  );
}

With a Git-based editor like SkyBlobs, you connect this repo, and the editor automatically detects your messages/ directory. The marketer opens the editor, sees hero.title, hero.subtitle, hero.cta as editable fields, makes changes, and submits a PR.

The developer sees a diff like:

// messages/en.json
{
  "hero": {
-   "title": "Build faster websites",
+   "title": "Ship your website 10x faster",
    "subtitle": "The modern development platform",
    "cta": "Get started free"
  }
}

Clean, reviewable, deployed on merge. No CMS API, no database, no build-time fetch.

Setting this up for an Astro site

The same pattern works with Astro content collections:

src/
  content/
    pages/
      home.yaml
      about.yaml
    blog/
      first-post.md
      second-post.md

Astro content collections use Markdown with frontmatter, and YAML or JSON for structured data. A Git-based editor handles all of these formats: Markdown with a rich text editor, YAML/JSON with structured form fields.

The team dynamic shift

The real benefit isn't just technical. It's organizational.

When marketers can self-serve content changes, the feedback loop shrinks from days to minutes. They try a new headline, preview it, submit the PR, and it's live after a quick review. They iterate faster. They experiment more. They stop filing tickets for one-word changes.

Developers get their time back. They're no longer the bottleneck for content updates. They review PRs instead of making the edits themselves. And because everything goes through Git, there's a complete audit trail: who changed what, when, and why.

Common objections

"What if they break something?"

They can't. The editor writes valid files, and changes go through a PR. If something looks wrong, don't merge it. The existing review workflow is your safety net.

"Our content structure is too complex"

If your content lives in files that your framework can read, a Git-based editor can present it. Nested JSON, multi-level YAML, Markdown with frontmatter: the editor handles the complexity so the marketer doesn't have to.

"We need approval workflows"

GitHub PRs are approval workflows. Require reviews, add branch protection rules, use CODEOWNERS to assign specific reviewers for content files. The tooling already exists.

"We have too many locales"

A side-by-side translation editor shows all locales at once. The marketer (or translator) sees English on the left, French on the right, and can work through changes systematically. Missing translations are highlighted automatically.

So what do you actually do?

You don't need to choose between a great developer workflow and a great marketer experience. Keep your content in Git. Add a visual layer for non-technical users. Use pull requests as the bridge.

Your static site gets to stay static. Your marketers get to move fast. Everyone wins.