The Radical Simplicity of Building a Website by Hand

The modern perception of what constitutes a "website" has become so burdened with expectations that the starting line feels impossibly far away. We imagine we need databases, templating engines, build processes, and hosting configurations before we can even begin. This creates a paralysis of preparation, where months pass in "planning" while nothing ever actually goes live.

But strip away everything we think a website should be, and you're left with something surprisingly elemental: a single HTML file. Not a "landing page" for a future project, not a placeholder, but actual content that exists on the web. The author's approach is deliberately anti-modern, suggesting we open TextEdit—yes, the basic text editor that comes with your computer—and write raw HTML. No syntax highlighting, no autocomplete, no frameworks. Just tags and text.

This isn't nostalgia for its own sake. There's a profound lesson in writing your first blog post as plain HTML. When you write <h1>Your Title</h1> and <p>Your paragraph</p> without any CSS to hide behind, you're forced to confront what the web actually is: a document delivery system. The browser's default styling—Times New Roman, black on white, blue underlined links—isn't a failure state to be immediately overcome; it's a functional baseline that works everywhere, for everyone, regardless of their device or connection.

The author insists on writing an actual post, not "Hello World" or Lorem Ipsum placeholder text. This matters because it shifts the mental model from "building a website" to "publishing writing." The website becomes a byproduct of having something to say, rather than a project unto itself. Name the file something meaningful, like how-to-make-a-damn-website.html, and upload it via FTP to a server you've acquired (the author acknowledges this part is "stupid and tedious" but necessary). Suddenly, you have a URL. A real, working website.

What makes this approach powerful is that it inverts the typical development workflow. Most people start with design, then structure, then content. This method demands content first, structure second, and design much later. The author calls this "shipping," and it's the critical step that 90% of aspiring website creators never reach. They get lost in choosing a CMS, designing mockups, setting up Git repositories, and all the other "busywork" that feels productive but produces nothing publicly accessible.

Once you have that first page live, the next step isn't CSS—it's RSS. This is where the philosophy deepens. An RSS feed is pure syndication, a way to push your content directly to readers without relying on social media algorithms or email newsletters. Writing it manually teaches you the XML structure: channel metadata, items with titles, publication dates, GUIDs, and descriptions. The description can contain the actual HTML from your post, wrapped in CDATA.

This manual process reveals something important about web standards. RSS readers render your HTML using their own stylesheets, which means your raw, unstyled markup needs to be semantic enough to look readable when stripped of your design. Writing HTML first forces you to use proper elements—headings, paragraphs, lists—because there's no CSS to fake it with. A <div> with a big font isn't a heading; a proper <h1> is.

The author provides specific technical details: use absolute URLs for images (since RSS readers fetch from outside your site's context), format pubDate in GMT, generate unique GUIDs (using an app like Tulip), and consider keeping only recent entries in the feed to manage file size. These aren't arbitrary rules—they're the accumulated wisdom of someone who has actually done this, repeatedly, and understands the practical implications.

After establishing content and syndication, index pages come last. This is the opposite of how most sites are built. Usually you start with a homepage and add content later. Here, you build a simple directory listing once you have multiple posts. The root index links to /blog/, which lists your posts. Basic HTML, no complexity.

Styling enters the picture only after you have several posts to use as reference material. The author recommends styling basic elements one at a time: h1, h2, p, strong, em, ol, ul. This incremental approach means you're designing for actual content, not hypothetical layouts. You can see how your typography choices affect real articles, how your color palette works with actual text, and whether your spacing makes sense for the length of your writing.

The broader implication here is a critique of modern web development's complexity. Tools like WordPress, static site generators, and modern frameworks solve real problems, but they also introduce layers of abstraction that distance you from the actual document. When something breaks, you're debugging build processes, plugin conflicts, or dependency issues rather than fixing HTML. The manual approach might seem inefficient, but it eliminates entire classes of problems.

There's also a philosophical stance about ownership and control. When you write your own RSS feed, you're not dependent on a plugin that might stop being maintained. When you upload files via FTP, you understand exactly where they live and how they're served. This knowledge becomes empowering rather than burdensome. You can migrate hosts, restructure URLs, or add new features without waiting for a platform to support them.

The author's final point is that "not doing this manually is what's hard." The complexity of modern web development often creates more problems than it solves. Automation is valuable when it handles repetitive tasks, but when it obscures fundamentals, it becomes a liability. Understanding how HTML, CSS, and RSS work at a basic level doesn't prevent you from using advanced tools later—it makes you a better user of those tools because you understand what they're actually doing.

This approach won't scale to enterprise applications or social networks, but it wasn't meant to. It's for personal websites, blogs, and small projects where the overhead of a full stack would outweigh the benefits. More importantly, it's a pedagogical tool that teaches the web's actual architecture by removing everything non-essential. You learn by doing the thing itself, not by configuring software that does the thing for you.

For those ready to try, the path is clear: write real content in raw HTML, upload it to a server, create an RSS feed manually, and only then consider styling. Each step builds on the previous one, and each step produces something publicly usable. The website grows organically from actual needs rather than imagined requirements. It's a philosophy that values shipping over perfection, understanding over abstraction, and simplicity over convenience.

The web started as a collection of manually created HTML files shared between researchers. In many ways, returning to that model isn't regression—it's a reminder that the fundamental value of the web is making information accessible. Everything else is optional.