Architecture / A technical note
A static site is a design decision.
Why a personal publishing space can start with HTML, local content, and a deliberately small runtime surface.
A personal website has a fairly simple job: introduce someone, show their work, and make their writing easy to read. For this site, those requirements led to a static export.
That choice is less about preferring one technology in the abstract and more about matching the architecture to the work it needs to do.
Start with what the page knows
An article already has its title, body, and publication date before anyone opens it. A project case study is the same. Neither needs to query a database on every visit to know what to render.
Next.js can generate these pages at build time. The deployed output is HTML, CSS, JavaScript, and other static assets. The hosting platform serves those files without running a Next.js server for each request.
That fits this site because its content changes through edits and deployments, rather than through visitor submissions or personalized requests.
Static does not mean inert
Most of a publishing site can arrive as readable HTML. Small parts can still be interactive: navigation, article filtering, or an independent technical demonstration.
The boundary matters. An interactive filter does not require making the article body a client component. A request-state demo does not require sending its supporting case study through the same interactive path.
Keeping the boundary narrow makes it easier to see where client-side behavior is needed and where a document is enough.
Treat content as part of the system
This site keeps project records in TypeScript and article bodies in Markdown. A local registry names each article, describes its metadata, and records whether it is published.
The same publication filter drives the index, detail routes, and sitemap. That is a small but useful constraint: an unfinished draft should not become public just because one list forgot to filter it out.
The workflow is straightforward:
- Write or edit the local content.
- Preview the page.
- Run the checks and build.
- Deploy the generated output.
This approach asks the editor to be comfortable with files and version control. For an individual engineering website, that is a reasonable starting point. A team with a different publishing workflow might make a different choice.
Be explicit about the limits
A static export cannot provide request-time server rendering, a database-backed contact form, or private account data on its own. Those features would need a separate service or a different deployment architecture.
For now, none is required here. Contact information can be a link. Writing can be a file. An interactive example can run entirely in the browser.
Build-time rendering also does not guarantee a fast or accessible site. Large assets, excessive JavaScript, unreadable type, and poor keyboard behavior can still get in the way. The architecture creates a useful starting point; the implementation still needs care.
Leave room for a real reason to change
The goal is an architecture that is easy to understand today and possible to extend tomorrow. A CMS, a server runtime, or an external service can be introduced when a concrete requirement makes it useful.
Until then, a directory of static files does the job this website actually has.
For a closer look at the implementation, see the website case study.