A personal blog rebuild that began as friction relief and became portfolio infrastructure — documented from day one with engineering journals, Astro, and a push back against default AI aesthetics.
Nothing was inherently wrong with my old blog.
It loaded. It had posts. People could read them. But the more I tried to change it, add a page, tweak the layout, publish something new, the more the whole thing felt like work I didn’t have energy for.
I had built the original site with older AI tooling and tried to keep the structure simple. Simple on paper, anyway. In practice, the patterns I had settled on added enough complexity that publishing felt burdensome. Old content curation was becoming its own drag on time and energy.
At home, both my kids are toddlers. At work, the schedule had been consistently intense, but it was also a learning environment. I didn’t need a rescue mission. I needed less friction between having an idea and getting it on the page.
So I said the thing out loud: I need to rebuild my blog from scratch.
I’ve kept an engineering journal for about four years, how I track decisions on professional and personal work alike. For the rebuild, I wanted that documentation to be the content strategy: log the work as I go, and publish from the journal instead of reconstructing everything in a separate pass later.
Two days later, I was part of a 22% workforce reduction.
The timing was fortuitous, in a complicated way. What had started as a publishing cleanup became something I could put directly to work in a job search that kicked off almost immediately, no longer a side project, but personal branding infrastructure.
I wanted the blog back online as soon as I could manage, publishing regularly again, with a project article I could point hiring managers at and say: here is how I think, build, and document work.
The first decision was deliberate: inventory everything before scaffolding the new site.
I audited the old library, posts, tutorials, long-form project files, lab drafts, templates, and wrote down what deserved to carry forward unchanged, what needed a rewrite later, and what should be archived. That editorial pass mattered more than picking a framework.
The policy that came out of it was conservative on purpose. Published non-project posts and the tutorial would migrate as-is, with original publish dates preserved. Longer experimental writing projects, Update Protocol and The Basilisk Papers, plus their announcement posts, would be archived until they meet the quality bar I want on a public site.
I still want to publish more experimental work. But I want to put my best face forward now, and those particular pieces, largely AI-assisted, longer-form, not as polished as I’d like, don’t belong in the first migration. The rebuild became a chance to decide what still represents me well.
The content model decision came early: Markdown and MDX in Git, with optional editor tooling layered on later if I need it. I wanted something durable, diffable, and portable, a CMS would have been solving a problem I don’t have yet.
For the site generator, Astro was the natural fit, file-based content collections, static output, RSS and sitemap without ceremony, room for interactive islands later without dragging along app complexity I wasn’t using.
At work, we’d been migrating some of our more static pages from Next.js to Astro. The performance wins were substantial. That experience nudged me toward the same direction for my own site, even though the personal rebuild had its own reasons.
Scaffolding wasn’t entirely smooth, the kind of mundane friction that doesn’t make a good tweet but does make a good journal entry. Tailwind landed through PostCSS because the Vite plugin and Astro integration didn’t play nicely with Astro 6. The React integration came out when the dev server started throwing Vite refresh errors despite there being zero React components on the site. Vite got pinned through npm overrides.
Hero images render only when the referenced file actually exists in public/. My AI Agent captured dated before/after screenshots as I went using a Playwright script against dev preview builds. This is actually pretty cool tooling I’m planning to extract and build out more to use on my other projects.
Unsexy choices in the moment. The kind you only notice if you skip them.
The first clean build gave me the homepage, post and tutorial pages, tag indexes, RSS, and sitemap, the real surface area I cared about, not a vanity page count inflated by auto-generated tag routes.
With the build working, I turned to where it would live. Source control moved off GitHub to Gitea on my home server. Deployment went to Cloudflare Pages via Wrangler direct upload, still manual, I haven’t wired up Gitea Actions yet, but that’s coming soon!
Ownership was the original driver. Increasingly, relying on third-party services feels dicier. We all watched GitHub uptime dip below 90% over a recent stretch. Bugs in core internet infrastructure feel more visible this year, even if I still depend on plenty of services I don’t control.
For personal projects, my goal is to bring as much under my own control as I reasonably can. My blog included. It’s also just good learning, running more of your own pipeline teaches you things a dashboard-only workflow never will.
Launch prep closed the migration loop: legacy URL redirects, an About page split out from an old Hello World post, refreshed privacy and AI content policies, a theme toggle, UTC-safe date formatting, and a social share widget ported from v1 without React.
The details matter when you’re asking someone to treat the site as professional work, Cloudflare _redirects in production, Astro middleware for local testing, small parity fixes that keep old links and new pages behaving consistently.
The migrated site worked. It also looked like what it was: a functional Astro scaffold with default-adjacent styling I hadn’t invested much in during v1.
The original styles were very typical of default AI outputs, competent, anonymous, not mine. Before calling the rebuild done, I wanted to pull the design into a more human-involved conversation.
The result is what I’ve been calling the Engineer’s Notebook look: warm paper in light mode; terminal-green accents in dark mode.
Inter for everything readable, JetBrains Mono for metadata and code. CSS-only motion, staggered card entrances, nav underlines, theme crossfades, with prefers-reduced-motion respected throughout.
It’s not done, and the updates are subtle… but it’s better than boilerplate.
The reading column changed the most on article pages, margin rule, prose styling, terminal-styled code blocks in dark mode:
A journal habit runs deeper than a single project, and has been invaluable for me.
Here’s what makes this rebuild different from a lot of AI-assisted project work I see in the wild: It self-documented deeply, as I built.
The repo includes engineering journal entries after each significant Agent session, a living meta-article draft, and before/after screenshots.
I created a story-journalist skill to bring it all together at the end to review those notes, and interview me to assemble to final narrative.
Wiring the journal into AI-aided projects is a hidden superpower compared to standard vibe-coding, where you generate a lot of code quickly but lose the thread of why decisions were made.
When I come back to write, interview, or apply for jobs, I don’t have to reconstruct context from memory. The context is already there to be queried.
I’m building my AI toolset with that in mind. Making documentation automatic isn’t overhead. It’s the whole point.
If your blog works but publishing feels heavy, you might not need a dramatic platform change. You might need an audit, a simpler content model, and honest editorial boundaries about what belongs on the public site today.
My blog is back up. The writeup you’re reading is part of the evidence. I’m publishing again, with a site that supports writing momentum instead of fighting it, and a rebuild story I can actually stand behind in a job search.
…and now it’s a solid portfolio piece too.
