The case for smaller websites

There’s a particular kind of project that starts with a landing page and ends with a platform. A newsletter becomes a community. A portfolio becomes a CMS. A single idea becomes a roadmap with four quarters of features.

None of that is inherently bad. But it’s worth asking, more often than we do, whether the thing would be better smaller.

The minimum viable site

A personal site can be six pages and a stylesheet. A small product can be one screen that does the job well. A documentation site can be a folder of Markdown and a search box.

The constraints aren’t limitations so much as filters. When you can’t add another feature, you’re forced to make the ones you have excellent. When there’s no dashboard, the empty state has to carry its weight. When there’s no onboarding team, the first screen has to explain itself.

Small sites have a way of exposing weak ideas early, which is exactly when you want to find them.

Speed is a feature you can feel

We’ve spent a decade optimising numbers that most people will never open a devtools panel to see. Meanwhile, the felt experience of the web — how quickly a page responds, how little it wobbles, how soon you can start reading — keeps getting worse.

A small site usually wins here by default. Less JavaScript means fewer things to parse, less to hydrate, fewer ways to jank. You don’t have to be clever. You just have to resist adding.

A craft argument, not a nostalgia one

I don’t think every site should look like 1998. I like animation, expressive type, and modern layout as much as anyone. The argument isn’t for fewer capabilities. It’s for fewer obligations.

The best small sites feel intentional in a way that large ones rarely do. Every pixel has a reason to be there, because someone had to decide. That’s the whole craft, really: deciding.