Writing First, Tooling Second - Susam Pal

Writing First, Tooling Second
By Susam Pal on 10 Jan 2026

I am a strong proponent of running
independent personal websites
on your own domains and publishing your writing there. Doing so
keeps the web diverse and decentralised, rather than concentrating
most writing and discussion inside a small number of large
platforms. It gives authors long term control over their work
without being subject to
changing policies
or incentives. I think that a web made up of many small,
individually run websites is more resilient and also more
interesting than one dominated by a handful of social media
services.

I often participate in discussions pertaining to authoring personal
websites because this is an area I am passionate about. Any
discussion about authoring websites that I take part in seems to
drift, sooner or later, into tooling. Aspiring personal website
authors worry at length about which blogging engine to use, which
static site generator to pick, which templating language to choose
and so on. I think none of this is important until you have
published at least five articles on your website. Just write plain
HTML and worry about tooling later.

This very website you are reading right now began its life as a
loose collection of HTML files typed into Notepad on a Windows 98
machine. I wrote some text, wrapped it in basic markup and copied
it to my web server's document root directory. That's it. Tooling
came much later, in fact many years later. As the number of pages
grew, I naturally wanted some consistency. I wanted a common layout
for my pages, navigation links, a footer that did not need to be
edited in twenty places. An early version of this website used HTML
frames to accomplish these goals. Later, I rewrote the website in
PHP. Now this website is generated using Common Lisp. All of these
additions came later, after I had been maintaining this website for
several years. None of this was required to begin.

Around 2006, when blogging had become quite fashionable, I
experimented with blogging too. Eventually, I returned to a loose,
chaotic collection of pages. I do have an
index page and an RSS
feed that resemble a blog, but they are simply a list of
selected pages arranged in reverse chronological order. The pages
themselves are scattered across various
corners of this website. My point is that
not every website needs to be a blog. A website can just as well be
a collection of pages, arranged in whatever way makes sense to you.
The blog is merely one possible organising principle, not a
requirement. If your goal is simply to share your thoughts on your
own web space, worrying about blogging and tooling can easily become
counterproductive. Just write your posts first, in plain HTML if
need be.

If you truly dislike writing HTML, that is fine too. Write in
Markdown, AsciiDoc or whatever plain text format you find pleasant
and convert it to HTML using Pandoc or a similar tool. Yes, I am
slightly undermining my own point here but I think a little bit of
tooling to make your writing process enjoyable is reasonable.
Tooling should exist to reduce friction, not to become the main
ceremony. Personally, I write all my posts directly in HTML. I use
Emacs, which provides a number of convenient key sequences and
functions that make writing HTML very comfortable. For example, it
takes only a few keystrokes in Emacs to wrap text in a
<blockquote> element, insert a code block or
close any open tags. But that is just me. I enjoy writing HTML
documents in Emacs. If you do not, it is easy to run your Markdown
files through a converter and publish the result with only a little
extra tooling overhead.

It is easy to spend days and weeks polishing a website setup,
selecting the perfect generator, theme and deployment pipeline, only
to end up with a beautifully engineered website whose sole content
is a single 'hello world' post. That might not be very useful to
you or anyone else, unless setting up the pipeline itself was your
goal. By contrast, a scrappy website made up of standalone HTML
pages might be useful to you as well as others. You can refer back
to it months later. You can send someone a link. You can build on
it gradually. Even if you never turn it into a blog, never add RSS
or never add any tooling, it still fulfills its most important
purpose: it exists and it says something you wanted to say.

So to summarise my post here: Create the website. Publish
something. Do it in the simplest way that lets you get your words
onto the page and onto the web. Once you have content that you care
about, tooling can follow. Your thoughts, your ideas, your
personality and quirks are the essence of your website. Everything
else is optional.

Comments |
#web |
#technology

Home
Links
Feed
Subscribe
About
GitHub
Mastodon

© 2001–2026 Susam Pal

This essay, penned by Susam Pal in 2026, offers a pragmatic and deliberately counterintuitive argument for the foundational principles of personal website creation. It prioritizes content creation – the act of articulating ideas and thoughts – above the often-overwhelming complexities of tooling, templating, and web development frameworks. Pal’s core assertion is that a website’s value resides not in its sophisticated architecture or technological sheen, but in the demonstrable presence of content. The piece advocates for a deliberately minimalist approach, urging authors to “Create the website. Publish something,” emphasizing the importance of getting words onto the web, regardless of the initial technical hurdles.

The essay’s structure is deliberately iterative, beginning with a stark warning against premature tooling. Pal recounts his own experiences, starting with a humble collection of HTML files typed into Notepad on a Windows 98 machine, progressing through the adoption of PHP and ultimately Common Lisp, all after several years of content creation. This personal narrative serves as a tangible illustration of his central tenet: initial focus should be on the substance of the writing itself. He describes a pattern of experimentation, constantly refining his website’s architecture—including a foray into blogging—only after establishing a continuous flow of content. This historical perspective highlights the tendency for aspiring web developers to become overly invested in selecting the "perfect" technological solutions before they’ve even produced a viable piece of content.

Pal’s argument against excessive tooling extends beyond mere technical considerations. He critiques the potential for paralysis created by an obsession with optimal website structure. He cautions against protracted periods spent configuring generators, themes, and deployment pipelines, specifically warning that such efforts could lead to a situation where a flawlessly engineered website contains only a single, rudimentary “hello world” post, ultimately rendering it superfluous. Instead, he champions a “scrappy” approach – a collection of standalone HTML pages – which he contends possesses a greater intrinsic value: the ability to be referenced, shared, and gradually expanded upon, irrespective of a formalized blog structure or extensive tooling.

Crucially, Pal recognizes the potential for individual preferences to dictate a website’s evolution. While he advocates for a core principle of prioritizing content, he acknowledges that methods of content creation—whether in plain HTML, Markdown, or AsciiDoc—should be chosen based on personal comfort and efficiency. He acknowledges the value of tools that reduce friction, but insists that they should serve as supplementary aids, not the primary focus of the process. His own preference for writing in Emacs, leveraging its key sequences to streamline HTML creation, underscores this point, while simultaneously allowing him to acknowledge that others may find alternative workflows more suitable.

Ultimately, Pal’s essay is a subtle yet powerful defense of the democratic potential of the web. By shifting the emphasis from technological prowess to the act of publishing, he advocates for a system where individual voices can be amplified without the constraints of centralized platforms or the demanding requirements of modern web infrastructure. The concluding summary – “Create the website. Publish something. Do it in the simplest way that lets you get your words onto the page and onto the web. Once you have content that you care about, tooling can follow” – represents a fundamental call to action, reminding creators that their core message is what truly matters.