Quick question for anyone building static sites:
Have you ever handed off a Hugo or Astro or Next.js site to a client…
and then instantly started getting messages like:
“Where do I change this text?”
“Why are my updates not live?”
“I think I broke something.”
If yes, you are not alone.
This has been the story of our lives for years.
We build websites for clients using static site generators like Hugo, Astro, and Next.js. We also manage several of our own business sites. And the pattern is always the same:
Non-technical people struggle with the SSG workflow.
For developers, the setup is beautiful.
Markdown plus Git plus a fast build pipeline is perfect.
But for non-developers, it is more like:
"Why is this so hard compared to Google Docs?"
What usually happens
When we hand off a site, the initial explanation goes well.
We show them the markdown files.
We show them the folders.
They smile and nod.
Then the questions start to flow.
- “Why is my change not showing on the website?”
- “What is frontmatter?”
- “Where do I update this image?”
- “Can you fix what I just did?”
SSGs give developers speed, control, security, and zero plugin drama.
But they are not designed around non-technical editors.
What we tried
We genuinely tried everything.
- Markdown guides
- Docs
- Loom videos
- Live Zoom training
- Slack support
- Prebuilt content templates
But at the end of the day, many clients still said:
"Can you update this for me?"
And honestly, we cannot blame them. Their entire writing experience in life has been shaped by Google Docs, Notion, Dropbox Paper, WordPress editors, etc.
Trying existing CMS options
We experimented with many Git-based and headless CMS tools.
Some were great but too complex.
Some required too much configuration.
Some did not work smoothly with our frameworks.
Some confused clients almost as much as the repo itself.
Eventually we spent more time supporting the tool than supporting the client.
So we built a small internal Git-based CMS
Since we have an in-house dev team, we finally built a small internal tool. Nothing huge. Just a clean, visual editor that writes directly to the repo behind the scenes.
We used it internally for a long time and it genuinely saved us hours of support every month.
We then shared it with a few clients, and they loved it.
That is when we realized the problem is bigger than just our team.
Soft launch and unexpected interest
We quietly released the tool publicly as a beta.
No launch event.
No announcements.
No marketing.
We still ended up with:
- more than 400 registered users
- some early paying customers
- lots of helpful feedback
Clearly, many teams feel the same pain when it comes to SSG content editing.
What is Sitepins?
Sitepins is a simple Git-based content editor built for static site generators like Astro, Hugo, NextJs, 11ty, Jekyll and more.
It connects to your repo and gives non-technical editors a clean, docs-style interface to update content without touching code.
Here is the basic idea:
- Developers keep their normal SSG workflow
- Writers and marketers get a familiar writing experience
- The system commits changes to the repo automatically
Sitepins works with anything that uses Markdown, JSON, YAML, or TOML, including:
- Hugo
- Astro
- Next.js
- 11ty
- Jekyll and more..
It is designed to feel as simple as Google Docs but still keep the power and flexibility of Git.
There is a free plan that works for many teams.
It is still in beta, so you might see a few things we are actively improving. If you try it, please take it kindly and feel free to share any feedback.
How do you handle content editing for non-technical users?
Genuinely curious to hear from the community:
- Do you teach clients Git?
- Do you update the content for them?
- Do you integrate a CMS?
- Do you avoid SSGs for client projects?
Would love to learn what works for you and what does not.
Top comments (0)