DEV Community: Idan Goldman

King Content is Dead, Long Live King Content

Idan Goldman — Tue, 14 Jul 2026 08:27:07 +0000

King Content lived a life of theory, hypothesis, and analysis, and died to live a life of thesis. Long live King Content II.

Ideas are perfect until they meet reality and adjustments must be made as Plan B or C (OK, more like Plan K-L-M-N-O-P). The exact same thing happened to me while writing Content is King. While the theory made perfect sense on paper, in practice it required real-world adjustments to become a thesis. In this field note, I will review what actually worked to keep my focus solely on content while moving the plumbing code aside.

Plumbing Code

The most significant architectural shift was replacing Quartz with Hugo and the Stack theme. For my specific use case, Hugo is simply a better-matched SSG, allowing me to minimize additions and extensions to the codebase.

Write > Preview > Publish > Read

The second major adjustment to the plumbing code was the forgotten step of previewing the website before publishing. I needed a way to review the look, feel, and theme of the website before publishing it live, rather than debugging it after the fact. To achieve this, I used Process Compose as a lightweight alternative to Docker Compose, reusing my existing scripts while keeping BASH scripting as the good old glue holding everything together.

For an expand version of tools used to glue the website togather, you can check out the README.md on the public GitHub repository mirror.

Structure

On the structural side, the biggest change involved decluttering the notebook folder. I split a single, flat list of files into 3 sub-folders:

archived: Content from previous website iterations that I still want to keep.
drafts: Ideas and active writings, which are excluded from the public mirror repository on GitHub, I want to keep an element of surprise — BOO!
published: Finalized writings live on the current website.

All other changes were minor cleanups of unused assets and content or small migrations to better-suited place for them.

Content vs. Plumbing Code Ratio: 2:1

...and instead of boring you with a Git repository tree code block, here is the breakdown of how the repository's files are distributed:

Asset	%	Files	%
Content	66.39%	Markdown	42.62%
		JPG	14.75%
		PNG	8.20%
		PDF	0.82%
Code	33.61%	HTML	7.38%
		SVG	8.20%
		YAML	7.38%
		TOML	5.74%
		Shell	2.46%
		SCSS	1.64%
		JS	0.82%

Workflows

For automation, I broke down one monolithic workflow into two smaller, single-purpose workflows, and added two helper workflows that I didn't know I would need in theory phase:

Release: Handles structuring the content and plumbing code in the right way for Hugo, building the static files, and packaging the website into a versioned ZIP file uploaded to the Forgejo Registry.
Publish: Pulls the latest versioned package from the Forgejo Registry and deploys it to Cloudflare Pages.
Mirror: Automatically maintains an up-to-date copy of the repository on GitHub.
Purge Packages: Automatically cleans-up older website builds from the Forgejo Registry to prevent disk space bloat and unexpected "insufficient funds" crush.

Writing Content

The one thing I still hypothesize on is my writing tools.

On macOS: I use iA Writer and VS Code.
On iOS and iPadOS: I use Obsidian with Obsidian Git plugin or Forgejo’s native web UI.

This isn't perfect setup yet, but gets the job done for me to continue and release-publish content to you the readers.

Thanks for reading, and see you in the next one.

A Thesis on Personal Website Architecture

Idan Goldman — Mon, 13 Jul 2026 09:28:03 +0000

For years, I had developer's block as a writer — trying to build/rebuild/optimize the website, putting my writings aside, chasing the perfect structure worthy enough to exhibit my thoughts, ideas, feelings, and work. All I wanted was a way to write and post the damn thing… yet all I did was code the damn thing, which got me blocked from writing the damn thing again and again. Now, I'm trying a new thing (for me): writing about how to build the damn thing while building the damn thing — dogfooding myself, if you will.

So… my current thesis is: content should be front and center, with everything else kept aside and to a minimum.

Focus on Content

Write > Publish > Read

Pretty simple, isn't it? While it looks like any other generic content-publishing flow out there, my peace of mind lies in the details — keeping plumbing code out of sight, hidden in a dot folder, while content resides in the git repository's root folder. Let me explain what I mean by that.

In any other SSG/CMS setup, the codebase is front and center and the content is just a folder or database entry that plays its part. I don't like that, because it takes my focus from writing the content to maintaining the codebase, as any other ADHD developer would.

This time, content files are the main focus — as they always should have been — while the code setup files sit in a "hidden" folder at the top of the git repository. That way, when I open the main folder in any editor, the content is right there and not in a side folder a couple of clicks down.

How it looks

web/
├── .forgejo/
├── about.md
├── home.md
├── notebook/
│   ├── april-fools-beginning.md
│   ├── i-want-to-tell-you-a-story.md
│   ├── month-of-flying-by.md
│   ├── public-beta-is-out/
│   │   ├── content.md
│   │   ├── staticpage-logo.png
│   │   └── staticpage-landing-page.png
│   ├── ready-to-go-full-time.md
│   └── ...
├── ...
└── studio.md

Well, what do you think? To my eyes the codebase clutter is gone, and all I'm left with is structured content — files and folders translated into web paths, with some code plumbing underneath, like:

about.md becomes /about/index.html
home.md becomes /index.html
content.md files inside folders become index.html
Any media files (like images) related to a piece of content live beside it, in a folder named after that piece of content.

How it works

The hidden piece of code plumbing (the magic) is done inside the .forgejo folder. Take a look:

.forgejo/
├── quartz/
│   ├── custom.scss
│   ├── quartz.config.ts
│   └── quartz.layout.ts
└── workflows/
    ├── build.yml
    └── deploy.yml

So, what do we have here? workflows and quartz folders — one for building and deploying the website's content you read here, and the other for the website's configuration and customization you see here.

Why Forgejo and Quartz?

Forgejo is easy: I already enjoy using it as my self-hosted git server and action runner. It runs blazing fast (in my setup) and has a snappy web UI, which helps.
Quartz… don't know yet, we will see. Seems like it's made for generating websites out of folder-based content structures like Obsidian's, and comes with supporting plugins to make life easier.

Workflows

The last part of this piece, before I jump into proving my thesis right, is how it all actually comes together — from writing a piece of content, through publishing it, to reading it on this website. The best way for me to explain is with a flowchart. So, here it is:

Yeah, I know it's a bit much for a personal website, and might change later.

The End

…and that's it, folks — thank you for reading! See you next time.

P.S. If you are reading this, the website is up and this content piece is already outdated on how the actual website got built. Wait a minute for the next post to read how the website was actually released and published.