Every developer I know has a graveyard of personal sites: the Gatsby blog from 2019, the Notion export from 2021, the "new one, this time for real" that shipped a hero section and nothing else. The sites do not die from lack of ideas. They die because publishing costs too much.
This site is my attempt to fix that with architecture instead of discipline. Three decisions do the work.
1. Lower the cost of publishing until it beats a tweet
If publishing a note requires a branch, a commit, frontmatter, and a deploy, I will tweet the idea instead and the site starves. So all content — posts, notes, experiments, even my learning progress — lives in Postgres and is edited through an admin panel on the site itself. Publishing a note is: open /admin, write, toggle to published. The public page revalidates on the spot through tag-based ISR:
"use server"
export async function publishNote(id: string) {
await requireAdmin()
await supabase
.from("notes")
.update({ publication: "published", published_at: new Date().toISOString() })
.eq("id", id)
revalidateTag("notes", "max")
}Markdown-in-a-database loses me git history for posts. It buys me instant publishing, relational tags, and full-text search across everything. For a single-author site, that trade is not close.
2. One content pipeline, many content types
Every section of this site — projects, notes, experiments, the changelog, this post — follows the identical lifecycle:
table → typed server query → ISR-cached page → admin Server Action →
revalidateTag
Adding a new content type is a new table and a new feature folder, not a new architecture. The sameness is the feature: I never re-decide how a section works, so section number eight cost an afternoon instead of a weekend.
3. A changelog as a forcing function
A portfolio shows what I finished. A changelog shows that I am still going. The monthly entries ("Learned X / Built Y / Improved Z") are short on purpose — they exist so the site always has a heartbeat, even in months where I ship nothing big. An empty month is visible, which is exactly the point.
What I would tell past me
- Do not build the perfect site first. Ship the pipeline, then let content accrete.
- Drafts must be first-class. Half this site exists because "save as draft" is safe and searchable later.
- Realistic seed data matters more than it sounds: a site that looks alive on day one gets treated like a living thing from day one.
The site you are reading is the artifact; the pipeline is the actual project.