Architecture Should Follow the Product's Job

When I planned this website, the obvious temptation was to treat it like a software product: use a client-rendered application, add a backend, introduce a database, and create a content dashboard.

That would have demonstrated more technologies. It would not have produced a better website.

The actual job of this site is straightforward. It needs to establish my professional identity, publish technical notes and case studies, load quickly, remain easy for search engines to understand, and require little operational maintenance. Those requirements point toward a static, multi-page architecture.

Starting with the job

I evaluated the site through a few practical questions:

• Does it require accounts or personalized content?
• Does it process transactions or maintain user state?
• Does it need real-time data?
• Will non-technical editors publish content every day?
• Does its value depend on complex client-side interaction?

For this site, the answer to each question was no. Most pages are durable documents: an About page, project explanations, and technical notes. They should arrive as complete HTML rather than depend on JavaScript to assemble their primary content in the browser.

I therefore chose Astro, Markdown content collections, and static generation. Cloudflare serves the generated assets, while a thin Worker handles delivery concerns such as security headers and redirects. It is not an application backend and does not contain business logic.

Multi-page does not mean unsophisticated

A multi-page website gives each important subject its own URL, title, description, canonical reference, and structured data. That is useful for readers and for search engines. It also makes individual notes and case studies linkable without turning navigation into simulated client-side state.

The website can still use restrained motion and small interactive components. The distinction is that its core content and navigation do not depend on them.

Complexity still exists

Static architecture does not remove every engineering concern. The site still needs validation, accessibility testing, content security policy checks, responsive behavior, redirect rules, structured data, and a dependable deployment pipeline.

The difference is that complexity is concentrated around requirements that exist. I am not also maintaining authentication, database migrations, server sessions, or an administration layer that the product does not need.

What would justify reconsidering?

I would revisit this architecture if the website developed a real requirement for private content, user accounts, personalized experiences, collaborative editorial workflows, or frequently changing data that cannot be prepared during a build. A client portal would probably remain a separate application rather than being mixed into the public authority site.

Choosing a smaller architecture is not a rejection of more capable tools. It is an attempt to match capability to purpose.

My current conclusion is simple: architecture should follow the product’s job. For a content-focused professional website, delivering complete documents with a small operational surface is the responsible default. More infrastructure should be introduced only when a verified requirement can explain why it belongs.