<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
<title>Mohammed Aadhil - Blog</title>
<description>Notes on building and shipping desktop apps, Zoho CRM development, and developer tooling.</description>
<link>https://aadhil.dev/blog/</link>
<atom:link href="https://aadhil.dev/blog/rss.xml" rel="self" type="application/rss+xml"/>
<language>en</language>
<lastBuildDate>Thu, 22 Oct 2026 00:00:00 GMT</lastBuildDate>
<item>
<title>Rebuilding aadhil.dev on Astro</title>
<link>https://aadhil.dev/blog/rebuilding-aadhil-dev-on-astro/</link>
<guid isPermaLink="true">https://aadhil.dev/blog/rebuilding-aadhil-dev-on-astro/</guid>
<pubDate>Thu, 22 Oct 2026 00:00:00 GMT</pubDate>
<description>Why I moved a hand-written index.html to an Astro static build - and why the interesting part was not the framework, but keeping every existing URL alive.</description>
<category>astro</category>
<category>cloudflare</category>
<category>web</category>
<content:encoded><![CDATA[<p>For years this site was a single <code>index.html</code> I edited by hand. It did the job
while it was only a profile page, but it quietly limited what I could do. Every
app release meant either writing no release notes at all, or putting them
somewhere nobody would find them.</p>
<h2 id="what-i-actually-wanted">What I actually wanted</h2>
<p>Not a framework. Two things: a <a href="https://aadhil.dev/changelog">changelog</a> I would keep up to date,
and somewhere to write. Both are content problems, and hand-written HTML is a
poor place to keep content.</p>
<p>Astro turned out to be the right size for the job. The built site is still a
pile of static files - no server, no client-side router, no JavaScript shipped
to pages that do not need any. What changed is that releases and posts are now
markdown files with a schema in front of them.</p>
<h2 id="the-schema-is-the-point">The schema is the point</h2>
<p>Every release and every post has its frontmatter validated at build time. A
missing date, or an app id that does not exist, fails the build and names the
offending field - rather than rendering a broken row I notice three weeks
later.</p>
<p>That sounds like a small thing. It is the difference between a changelog I
trust and one I have to proofread.</p>
<h2 id="not-breaking-anything-on-the-way">Not breaking anything on the way</h2>
<p>The real constraint was that every existing URL had to keep working. The
Flatpak manifests for my Linux builds fetch their release archives straight off
this domain, and several store listings point at privacy pages here. A broken
URL in that set is a broken install, not a 404 someone shrugs at.</p>
<p>So the old paths moved across untouched, and I diffed the built output against
the old site before shipping - rather than assuming a reorganisation had been
harmless.</p>
<h2 id="where-it-runs">Where it runs</h2>
<p>Cloudflare Pages, built on push. Deliberately boring.</p>
]]></content:encoded>
</item>
</channel>
</rss>
