DEV Community: Asahi Fujisawa

Why I Built a Headless CMS on Top of GitHub (and What I Learned as a Solo Founder)

Asahi Fujisawa — Fri, 01 May 2026 14:53:27 +0000

I love Jamstack. I've built a lot of sites with Next.js — personal projects, client work, side products. The pattern clicks for me: static by default, dynamic where it matters, deployable anywhere.

But every time I needed to manage content, I hit the same wall.

The problem with headless CMS tools

The cloud-based options — Contentful, Sanity, Prismic — are genuinely good. But they come with pricing tiers that feel arbitrary when you're a solo developer with three projects and a limited budget. You start free, you grow a little, and suddenly you're deciding whether a blog is worth $99/month.

The open-source alternatives (Strapi, Payload, Directus) are powerful, but they require a server and a database. That's not a complaint — it's just not what I wanted. I didn't want to provision infrastructure to publish a blog post.

What I actually wanted was simple: a free, cloud-native headless CMS with no server to run and no credit card required.

Then I thought: wait. I already have GitHub.

GitHub is already a content store

Think about what a GitHub repository gives you out of the box:

File storage (Markdown, JSON, images)
Version history on every change
A complete REST API to read any file
Access control via tokens
Zero hosting cost

It's not a CMS. But it has everything a CMS needs to be built on top of it.

So I built @asahi-fj/structcms — a small npm package that fetches and transforms content stored in a GitHub repo into structured data your app can consume.

npm install @asahi-fj/structcms

import StructCms from "@asahi-fj/structcms";

const cms = StructCms({
  token: process.env.GITHUB_TOKEN!,
  owner: "your-org",
  repo: "your-content-repo",
});

const posts = await cms.getAll();

A token, an owner, a repo. You get back typed content. That's the whole setup.

Why not just use the existing tools?

There are projects that do something adjacent — Outstatic, Decap CMS, Contentlayer. I looked at all of them.

Outstatic requires the content to live in the same repo as your app. Decap CMS needs Netlify or a Git Gateway. Contentlayer reads from the local filesystem — great for monorepos, but useless if you want to share content across projects.

None of them let you point at an arbitrary GitHub repo, owned by anyone, and just fetch the content with a token.

That specific combination — separate content repo, private repo support, zero infrastructure — is what I wanted. So I built it.

Content structure

Content lives under a contents/ directory. Each entry is a slug-named folder with two files:

your-content-repo/
└── contents/
    ├── hello-world/
    │   ├── content.md
    │   └── meta.json
    └── getting-started/
        ├── content.md
        └── meta.json

meta.json handles structured metadata:

{
  "title": "Hello World",
  "publishedAt": "2026-04-11",
  "draft": false,
  "tags": ["typescript", "jamstack"]
}

content.md is plain Markdown. No frontmatter gymnastics, no special syntax. Write it anywhere, commit it, and it's live.

The unexpected use case

After I published this on npm and wrote about it on Zenn, someone pointed out a use case I hadn't thought of: AI-generated content pipelines.

The idea is to point a Claude Code agent at the content repo. It reads existing posts, learns the writing style from the commit history and file structure, then generates new articles. Those articles get pushed back to the repo. The next generation has more examples to learn from.

Because structcms keeps the content repo separate from the app repo, you can run this loop without touching production code at all. The agent only writes to contents/. The app calls cms.getAll() and stays completely unaware of how the content got there.

I didn't design for this. But it makes sense. Git is already the right place to review AI-generated content — you can diff it, revert it, approve it before it goes live. The infrastructure was already there.

What this has to do with being a solo founder

I'm building another product in parallel — Ordia, a Slack-native tool for engineering teams. It monitors Jira and GitHub to surface stalled tickets and blocked PRs, proactively, without requiring engineers to change how they work.

structcms started as something I needed for my own projects. But building it taught me something I keep coming back to with Ordia too: the best tools are the ones that disappear.

structcms has almost no API surface. Two methods. No config files, no plugins, no admin UI. It does one thing — gets content out of a GitHub repo — and gets out of the way. I had to resist the urge to add more. A webhook system. A preview mode. A caching layer. All of it would have made it heavier and harder to trust.

The same instinct drives how I'm building Ordia. No new UI to adopt. No per-user accounts to set up. It works through Slack, which engineers already have open, and surfaces information they were going to look for anyway. The goal is always to reduce friction, not just change what the friction is.

Requirements and links

Node.js 18+
GitHub Personal Access Token with read access to the content repo

npm install @asahi-fj/structcms

Source: github.com/asahi-fj/structcms

If you're building on Jamstack and want content management without the infrastructure overhead, give it a try. And if you're also thinking about how to make developer tooling less interruptive — I'd love to hear what you're working on.

Your team is shipping faster than ever. That might be your biggest problem.

Asahi Fujisawa — Fri, 01 May 2026 13:54:19 +0000

I spent three days refactoring code that should have taken three hours.

The project was a voice recognition SaaS — Next.js on the front, FastAPI on the back. The original MVP had been built fast. Really fast. AI-assisted, prompt-driven, vibe-first. It worked. Users could log in, the core flows ran, nothing was on fire.

Then I had to touch it.

What I found: a single file with six unrelated methods sharing state in ways nobody had documented. Variable names that made sense to an AI in the moment — handleProcessV2, tempDataFinal, newLogicRefactored — but communicated nothing about intent or ownership. Comments that described what the code did, not why it existed. Dead code scattered throughout, still referenced in two places, doing nothing.

The actual bug I was fixing was small. But to fix it safely, I had to understand the blast radius. And that took three days, not three hours.

That gap — three hours versus three days — is what I now think of as Comprehension Debt.

Technical Debt you know. Comprehension Debt is different.

Technical debt is when you take a shortcut and promise to clean it up later. Engineers have managed it for decades — it's in your backlog, it has a ticket, someone owns it.

Comprehension Debt is when your codebase grows faster than your team's collective understanding of it. There's no ticket for it. Nobody owns it. It's invisible until someone has to touch something.

AI coding tools produce Comprehension Debt at scale, and they do it quietly.

The code works. The tests pass (if there are tests). The PR gets merged. Leadership sees velocity metrics improving. Developers feel productive. And underneath all of that, the cost of understanding is being silently deferred — sprint after sprint.

When that cost comes due, it doesn't feel like a debt payment. It feels like entropy. It feels like your team is just getting slower for no clear reason.

What this looks like in practice

Here's the pattern I've seen, and that research is now documenting at scale:

Day 1: The AI-assisted feature ships in an afternoon. What used to take a senior engineer two days now takes two hours. Everyone is impressed.

Day 30: A bug appears in that feature. A developer opens the file. The function is 200 lines long, handles four unrelated concerns, and was clearly assembled from multiple AI-generated fragments that nobody connected into a coherent whole. The fix takes two days instead of two hours.

Day 90: The same developer gets asked about another feature in the same area. They say it'll take "a week to be safe." Nobody questions it because the codebase just feels complex now. But nobody can point to why.

This is Comprehension Debt compounding. And it's happening on teams right now — not because engineers are careless, but because AI coding tools are optimized for generation, not for the human understanding that follows.

A large-scale study of 8.1 million pull requests found that technical debt increases 30–41% after AI coding tool adoption. Vibe-coded projects accumulate technical debt roughly three times faster than traditionally written ones — not because the code looks wrong, but because it lacks the documentation, test coverage, and architectural coherence that comes from a human who actually thought through the system design.

The specific failure modes

In my experience — and in what I'm hearing from other teams — Comprehension Debt concentrates in predictable places:

Responsibility collapse: Logic that should live in three separate modules ends up in one file because the AI generated it together and nobody restructured it. You can't change one thing without understanding everything.

Naming that made sense to a prompt: AI-generated variable and function names often reflect the prompt that produced them, not the domain they operate in. processUserAudioV3 tells you nothing about what changed from V2, or why V3 exists.

Absent rationale: Traditional code accumulates informal documentation — commit messages, PR descriptions, inline comments that explain why a decision was made. AI-generated code skips this layer entirely. You inherit the decision without the reasoning.

Dead code at scale: AI assistants frequently generate helper functions, fallback handlers, and utility methods that never get called. In a human-written codebase, these get caught in review. In a vibe-coded codebase, they accumulate, cluttering the dependency graph and making blast radius analysis harder.

Invisible test coverage gaps: GitHub's research shows developers complete tasks 55% faster with AI coding tools. Test writing velocity does not keep pace — it stays the same, or gets worse, because the code is harder to understand and test boundaries are blurry.

Why this is an engineering management problem, not just a code quality problem

Individual developers feel this. But engineering managers are the ones who absorb the consequences without seeing the cause.

The symptoms look like this:

Tickets that used to close in a day now take three
"Simple" changes keep having unexpected side effects
Developers are reluctant to touch certain parts of the codebase
Estimation accuracy is declining sprint over sprint
Standups spend more time on "still blocked, investigating" than on progress

None of these symptoms point directly to Comprehension Debt. They look like normal engineering friction. They get attributed to scope creep, team capacity, or just the inherent complexity of the problem domain.

But the actual cause is that your team is operating a codebase they don't fully understand — and that gap is widening every sprint as AI-generated code continues to be merged without the comprehension layer being built alongside it.

What you can do about it

I'm not arguing against AI-assisted development. I use it daily. The velocity gains are real and the economics of ignoring them are bad.

But there are specific practices that prevent Comprehension Debt from accumulating:

Make understanding a merge requirement, not a review nice-to-have. Before AI-generated code merges, someone on the team — not the author — should be able to explain what it does, why it exists, and what breaks if you remove it. This isn't gatekeeping. It's the minimum standard for code that will run in production.

Treat dead code as a blocker, not a backlog item. AI assistants generate dead code constantly. Remove it at the point of generation, not later. Later never comes.

Write the rationale, not just the code. Commit messages and PR descriptions should explain decisions, not summarize diffs. AI can write the diff. Only a human can write the reason.

Surface stall signals early. Comprehension Debt reveals itself as stalled tickets — someone is blocked because they don't understand the codebase well enough to move. If a ticket sits in "In Progress" for three or more days with no update, it's a signal worth investigating, not a standup detail to acknowledge and move past.

That last point is why I built Ordia. After the three-day refactor I described at the top of this post, I started thinking about what would have helped. Not better AI tools — the AI was fine. What was missing was visibility into where the team was stuck, and why. Ordia monitors your issue tracker and code host automatically and delivers a morning digest to your team chat: stalled tickets, unreviewed PRs, blockers before they become delays. It doesn't fix Comprehension Debt. But it makes it visible before it costs you a sprint.

The real question

AI coding tools have changed what it means to ship software. Writing code is no longer the bottleneck.

Understanding it is.

The teams that figure out how to maintain comprehension — across the full codebase, across the full team, at the speed AI-assisted development runs — are the ones that will actually compound the velocity gains instead of spending them on debugging sessions nobody can explain.

The vibe was good. Now comes the understanding.

I'm building Ordia — a tool that surfaces stalled tickets and forgotten PRs to your team chat every morning, so engineering managers have visibility into where the team is blocked before it delays the sprint. If the problem described in this post resonates, I'd genuinely like to hear what it looks like on your team.

🚀 Introducing Sophina – AI-Powered Knowledge Management for Teams

Asahi Fujisawa — Sun, 28 Sep 2025 13:12:53 +0000

Introduction

Hi everyone!
We’re excited to announce the public beta of Sophina,
a platform that helps teams capture, organize, and retrieve company knowledge with the power of AI.

Modern teams struggle with scattered documents, outdated wikis, and endless Slack threads.
Sophina solves this by putting all your business knowledge in one searchable, intelligent hub.

What Is Sophina?

Sophina is an AI-driven knowledge management tool that enables you to:

✨ Automated Summaries – Convert long reports into concise, easy-to-read briefs.

👥 Team Collaboration – Shared workspaces keep everyone aligned and up-to-date.

🔒 Enterprise Security – Data encryption and strict privacy controls.

Why We Built It

As developers and product builders, we’ve often faced this all-too-familiar challenge:
information scattered everywhere, onboarding new team members taking forever, and documentation getting lost along the way.
On top of that, there’s a growing trend of “just let AI write the code,” which sometimes means that while software functionality stays the same, the quality of the source code itself can suffer.

Creating software that lasts requires maintaining a culture of humans writing code.
But in the AI era, that alone isn’t enough to keep up with the speed demands of modern development.

That’s where Sophina comes in.
Sophina is designed to centralize your team’s knowledge and leverage AI to instantly search and organize information, helping teams achieve both speed and quality at the same time.

💡 A new way of knowledge management that lets development teams move fast without compromising accuracy.

Try It Out

Sophina is live in public beta.
👉 Sign up here
to create a free workspace and explore all features.

We’d love your feedback, bug reports, or feature requests.
Drop a comment below or reach us at info@sophina.biz.

What’s Next

Integrations with Slack, Notion, and GitHub

More powerful analytics for knowledge usage

Mobile app support

TL;DR

Sophina centralizes company knowledge and makes it instantly searchable with AI.
Perfect for startups, remote teams, and anyone tired of digging through endless docs.

Closed Beta Now Open: We Built an AI Tool That Makes Task Management Effortless

Asahi Fujisawa — Tue, 27 May 2025 06:52:18 +0000

Why We Built This

There were two main reasons behind the development of this service:

In software development, breaking down client requests into actionable tasks is a recurring pain point. I believed AI could help with this process, saving time for what truly matters—spending it with loved ones.
I'm not great at parsing long meeting notes and converting them into tasks. It’s mentally draining and time-consuming, so I wanted AI to take that burden off and let me focus on building.

Key Features

1. Auto-generate tasks from text using AI

Just copy-paste documents or meeting notes, and the tool will extract tasks automatically.

2. Simple, intuitive UI

Designed for ease of use with minimal clicks and clean layout.

3. Easy integration with Jira

Import your current project data in one go using the Jira API.

The Vision

Working in IT often comes with long hours and high stress. My hope is that tools like this can give developers more time and mental space to enjoy what they love—whether that's a hobby or time with family. By eliminating repetitive tasks and minimizing miscommunication, we aim to create happier, more efficient dev environments.

Want Early Access?

Thank you for reading!

If you're interested in trying this tool, please join our waiting list from the link below. We’re currently limiting access to the first 30 accounts. (If the cap is reached, we may not be able to grant access—sorry in advance!)

👉 Join the Waiting List