All tests

PRISM JOURNAL

Why I Built My Own CMS Instead of Choosing One: Making Myself Legible in the AX and GEO Era

After moving through Strapi, Ghost, Notion, and Sanity, I ended up building my own operating structure with a separate portfolio blog layer and CMS layer. This is the first note in a series on how I think a personal site should be designed in the AX and GEO era.

These days, there are countless CMS options. There’s Strapi, Ghost, Notion layered into a publishing workflow, and tools like Sanity with a flexible structure. I tried wiring several of them into this blog myself. I simply wanted a smoother way to write.

The more tools I tried, the clearer one question became. Not "Which one should I use?" but "What problem am I actually trying to solve?"

For a while, I was basically a CMS nomad. I tried Strapi, hooked up Ghost, experimented with simplifying my workflow through Notion, and rebuilt the structure again with Sanity. Each had obvious strengths. Some were quick to start with, some were flexible in content modeling, and some gave a polished enough experience for running a blog.

I also rebuilt this SikLimited blog four or five times because I wasn’t happy with the CMS or the design. I never really settled anywhere. I kept putting off building something new because it felt too annoying to start from scratch... and then I ended up building it anyway. A big reason was that existing CMS products didn’t have the features that fit the way I work, and they were hard to customize. I also tended to stop using them. At some point I thought, maybe if I at least have to maintain it, I’ll keep writing too.


After trying all those CMSs, one discomfort kept coming back. My site could not be explained as just a blog.

It needed writing, but it also needed project work. Some pages had to be open to anyone, while others needed to be visible only to people with a specific link. After publishing, I also wanted to manage search engine indexing, SEO/GEO optimization tools, metadata, analytics, tracking, and an editing flow connected to AI tools. It may sound like overkill, but a simple posting feature always felt slightly lacking. What I was looking for was less a single CMS product and more an operating structure that matched the way I work.

That idea became sharper once I started hearing terms like AX and GEO. I’m not trying to make some grand argument about the times. But if you run a personal site, you can feel the shift pretty clearly. Before a person reads your site, search engines and various agents now read it first, summarize it, cite it, and judge it. A personal site is no longer just a few nice pages and a handful of posts. It has become something you have to design around discoverability, structure, and which sentences are likely to be quoted.

The turning point was surprisingly small. It started with Codex credits I received from Kakao. More than wanting to build some grand product, I had a simpler thought: maybe this is enough to rework my own workflow a little. That small trigger made me stop looking for a less inconvenient tool and start bundling the tools around the way I actually work.

So now I run a separated structure: a portfolio blog layer and a CMS layer. It runs on Cloudflare Workers and D1. I keep a CMS where I can directly manage writing and project work, while the public layer is structured so the portfolio and blog are what people actually read. On top of that, I’ve been gradually attaching things like automatic indexing, Google Analytics, Umami tracking, MCP server connections, and SEO/GEO optimization automation.

The CMS I built myself. Its name is Karma.
The CMS I built myself. Its name is Karma.

What matters is not that it has many features. What matters more is that all of those features are pointed at the same problem. I didn’t want to build a tool that simply stores content. I wanted a structure that helps the work I make under my own name get found, read, and passed along more accurately.

For example, I didn’t want every project to be open to everyone like a public blog post. Sometimes I wanted something to be visible only to people with a specific link, like in a hiring process or a collaboration proposal. So I built in a way to issue access links and track the flow coming through them. Not long ago, I even broke Umami tracking while changing the route structure, and that reminded me of something again. Owning the structure yourself gives you freedom, but it also means you have to keep tuning that freedom yourself.

So this post is less a claim that "what I built is better than any off-the-shelf CMS" and more a record of why I ended up bundling together a structure that fits my own hands. Strapi, Ghost, Notion, and Sanity were all good tools in their own way. But for me, portfolio, writing, gated sharing, search visibility, analytics, and AI workflows kept pulling in different directions, and I needed a way to hold them together.

Running a personal site is becoming less about uploading writing and more about designing how that writing and project work move through the world. Rather than interpret that shift in some grand way, I chose to operate it directly on a small scale. The result is this CMS.

In the next post, I want to write more concretely about why I ended up treating this structure less like a simple writing archive and more like a distribution system, and how I think about the portfolio layer and the CMS layer as separate things.

#CMS#AX#GEO#Personal Branding#Cloudflare Workers#D1#Umami#Google Analytics#SEO#Portfolio
kojaen