A personal digital garden and project portfolio, built data-first with a relational backend and a fully decoupled front end. The site itself is the first project documented on it.
Why build from scratch
I wanted full control over both the data model and how content gets presented — no CMS telling me what a project page has to look like.
The useful consequence showed up later. Adding the projects archive needed twelve new columns and two new tables, and changed nothing that already existed, because the original schema separated what every entry has from what each type has.
One graph, four kinds of content
Everything is an entry — a shared row with an id, a slug, a title and a date — plus a satellite table holding whatever is specific to that type. Projects, logs, photos and reading all sit in the same graph, share the same tag vocabulary, and can link to each other without any of them knowing what the others are.
Anything that varies per entry rather than per type lives in an ordered blocks table as JSON. This paragraph is one of those rows.
- Tables
- 12
- Frameworks
- 0
- Origin servers
- 0
- Build-time DB reads
- 0
No framework on the front end
There are no client islands anywhere on this site. The homepage — a booting CRT, a draggable window manager, a day/night cycle timed to music and a complete Minesweeper — is plain ES modules, one system per file.
That was a choice about where the complexity should live. A framework would have made the window manager easier and the 60 fps landscape harder, and the landscape is the part visitors actually notice.
Rendering
Every page is server-rendered per request on Cloudflare Workers, reading D1 through Drizzle. Nothing is baked at build time, so editing a row in the database is the whole deployment step for content.
The cost is a database round trip on a cold page. The benefit is that there is no build to run, no cache to invalidate, and no drift between what the database says and what the site shows.