Building eldritchit.me with Astro

I chose Astro before I knew how to use Astro.

The architecture made sense on paper: Markdown for articles, shared layouts for presentation, GitHub for history, and Cloudflare for deployment. Turning that idea into a site I understood was a different kind of work.

I did not learn the framework by completing a tutorial from beginning to end. I learned it one missing feature and one failed build at a time.

Starting with the official template

The site began with Astro’s blog starter.

There is no value in pretending otherwise. I did not need to prove that I could recreate a header, RSS feed, and content collection from an empty folder. I needed a working foundation I could inspect and change.

The starter solved that problem, but the first version still looked and behaved like a starter. It carried placeholder branding, generic copy, default layouts, and assumptions that did not match what I wanted Field Notes to become.

The real work was replacing those assumptions one at a time.

I changed the branding, rebuilt the homepage, revised the article layout, separated drafts from published content, added topic archives, implemented series navigation, added a reading-progress indicator, created legal and editorial pages, and prepared ad placements that stay out of the way when they are not configured.

At some point, the project stopped feeling like a modified demo and started feeling like my site.

Content collections forced useful structure

Markdown made writing easy, but the site still needed consistent metadata.

Every published article now has a title, description, publication date, category, tags, and optional series information. Astro’s content schema turns those fields into a contract instead of a suggestion. If a value is missing or shaped incorrectly, the build can catch it before the article reaches production.

Separating drafts taught me another important lesson: unpublished content should be excluded by the loader, not merely hidden from a listing page. If the content enters the public collection, another route or feed can expose it accidentally.

That is a small implementation detail with a very visible consequence.

Real features taught me the framework

Each feature forced me to understand another part of Astro:

• Drafts taught me how loaders and glob patterns work.
• Categories and tags taught me how schema data flows into dynamic routes.
• Series navigation taught me to sort and relate content predictably.
• Related articles taught me to avoid repeating selection logic across pages.
• A failed topic-page build taught me how code inside getStaticPaths() is bundled.
• Canonical URLs taught me that a site can render correctly while still publishing incorrect metadata.

A tutorial can demonstrate each feature cleanly. A real project exposes the decisions around it: where metadata belongs, which logic should be shared, what happens at build time, and how unfinished work stays private.

Those decisions are what made the lessons stick.

Small commits became the feedback loop

Cloudflare rebuilds the site when changes reach the main branch, but I do not want production to be the first place a mistake appears.

The repository’s full local check is deliberately simple:

npm run check

That builds the Astro site, runs TypeScript, and performs a Cloudflare deployment dry run. It cannot prove every page is good, but it catches structural failures before a commit becomes a public deployment.

The workflow also encouraged narrow commits: fix the canonical domain, add a policy page, improve article metadata, or correct a broken topic route. The repository history now shows how the site evolved, which is useful documentation by itself.

What I still do not know

Using Astro for one site does not make me an Astro expert.

There are parts of the framework I have not needed, and there are probably cleaner ways to solve some problems already in the codebase. That is normal.

My goal was never to master every feature before publishing. It was to understand the pieces I use well enough to maintain them, recognize when something is wrong, and improve the site without starting over.

That is a more useful standard than waiting until I feel qualified to begin.

Key takeaways

• A starter template is a foundation, not a finished identity.
• Content schemas and draft exclusions prevent editorial mistakes from becoming public ones.
• Real features teach framework boundaries more effectively than copying a completed tutorial.
• Small commits and one repeatable check make failures easier to understand.

What I would do differently

I would define the content model and publishing workflow before redesigning the homepage.

The visible design was satisfying to change, but categories, tags, drafts, URLs, and series order shaped the entire publication. Establishing those rules first would have reduced later cleanup.

I would also add the full check command on day one and review generated changes before stacking more features on top of them. That lesson became the basis for cleaning up the AI-assisted site.

AI transparency

AI helped explain unfamiliar Astro concepts, review code, draft portions of the implementation, and edit this article. I reviewed the changes, resolved deployment failures, and made the final decisions about the site’s design and structure.