The Resurgence of the Webmaster

If you browsed the web in the late 90s or early 2000s, you’ll remember the term webmaster.

You’d see it in the footer and on 500 pages — “contact the webmaster” — a single person you could email about everything that happened between what the site was meant to achieve and whatever actually showed up on your CRT.

Somewhere along the way, we stopped saying it. The label faded as the web professionalised and platformed itself into something bigger than a handful of hand‑edited pages.

But I’m seeing the shape again: in people who can hold taste and implementation together. And in those who choose to take responsibility for their own corners.

Maybe webmasters are coming back.

When Nobody Else Knew How to Use the Web

The job was part sysadmin, part content editor, part designer, part miscellaneous web wizard. One person would keep the server alive, configure Apache, juggle FTP credentials, and hand‑edit a pile of .html files full of inline styles and hard‑coded layout.

They weren’t just keeping pages online. They chose how content was consumed — type, colour, layout — then made it real, wielding nested tables as their weapon.

The early web I remember was rough, chunky, and static: browser‑default fonts, hard‑edged form elements, table borders everywhere, the familiar “under construction” GIF. I’d wait on dial‑up to see pages load in IE6, then put in the effort to decode whatever clunky layout appeared.

For a while, the challenge was making the table cells line up — and hoping it worked in Netscape. Then CSS showed up: the web got more expressive. Perhaps that was the moment the webmaster’s grip started to slip. Remember the Space Jam website? It’s become a signifier for that era — we look at it now and laugh, but it’s a useful reminder that early “web design” mostly meant squeezing something — anything — onto a glowing rectangle with rudimentary tools.

Expectations were low, because the medium was new. Simply having a site online felt like an achievement. And the webmaster wasn’t just “implementing the design”. They were the person holding the whole thing — content, layout, aesthetics, accessibility, compatibility, and keeping the servers humming along.

To date myself, I joke that I’ve been “designing since IE7”. My first website was built with the Lycos page builder, proudly attached to an edgy teenage‑angst .tk domain. Around the same time, my dad’s mate handed me one of his PHP books and warned me not to order too many pizzas or start listening to Metallica.

From the perspective of that teenage boy — sat at a Windows XP computer, peering through the browser window — the webmaster was the mysterious being who seemed to know how the whole contraption stayed alive.

Absorbed by Web Apps and Roles

As the web matured, people wanted to do things online — and they wanted those experiences to feel intuitive, delightful, beautiful, blazing fast, secure, and reliable.

We didn’t just add a few features. Desktop tasks moved into the browser: spreadsheets for balancing the books, documents for collaborating, workflows that used to live in client apps. We turned websites into applications: front‑ends and databases, APIs and background jobs. Multi‑tenant SaaS deployments that require monitoring, scaling and reliability. The surface area exploded inline with the expectations.

The webmaster didn’t vanish because the role was trivial or misguided; it was gobbled up by the requirements of building and operating modern web software. One person could no longer reasonably understand a business domain, design rich new flows, keep servers healthy, and ship features at a competitive pace.

The old caretaker of a handful of pages suddenly found themselves in a new, foreign world of machines and tools they were never quite designed to tend.

So we pulled the role apart and turned it into an ecosystem: designers, engineers, product people, researchers, architects. We industrialised the path from idea → interface → implementation into something that looked clean on a gantt chart.

1. Product people decide what users do.
2. Designers make tidy mock‑ups of what users see.
3. Engineers work through tasks to make the picture real.

There’s a comforting clarity there. Phases are bound by role. Inputs and outputs are obvious. You can grade and track work.

But building good software that follows the grain of the medium doesn’t actually work like that. The moment a team tries to make something feel good — not just functionally correct — you loop. You learn things only once code is running. You adjust the design based on what’s possible, what’s legible, what’s accessible, what’s viable inside the business.

And you rewrite the implementation because building the thing changes what “desirable” even means. You learn; the target moves.

And we spent a couple of decades telling ourselves that ecosystem could still be sliced neatly between modes of “designing” and “engineering”.

Absorbed by Silos

The story isn’t just about how the web gets built; it’s also about where web life happens, and who owns the walls around it.

In the earlier days, the web was decentralised by default. People ran their own weird little websites on shared hosting, university servers, GeoCities, or a box under your desk. Each site was its own small artefact: somebody’s taste, ability, and curiosity frozen into HTML.

As platforms grew, more of everyday web life moved into central silos. Instead of tending a personal site, you posted into feeds. Having a presence on the web shifted from owning a corner to being a guest in somebody else’s product.

That made sense for a lot of people. It was easier than wrangling FTP, DNS, and CSS. But it also commoditised the experience of the web — and, over time, many of those platforms have “enshittified” the deal: more ads, more tracking, more engagement hacks, and less control.

In response, there’s been a growing counter‑movement — the IndieWeb, the “small web”, people once again hosting their own blogs and strange little sites.

That current reopens a question the webmaster once answered: who takes responsibility for having enough of the skills, taste, and patience to build and look after these individual corners of the web?

The Webmasters Among Us

Today, the web is in a strange place: both easier and harder to wrangle.

Easier, because mature frameworks, design systems, and hosting let a single person ship something robust without reinventing everything. Harder, because expectations are higher and the constraints are more vast and detailed — the web platform has grown a whole new set of APIs and capabilities.

Even in teams composed of heavily specialised minds, job titles and responsibilities are messy. People bleed over the edges of their boxes all the time, and the reality is usually a spectrum of overlap rather than tidy, isolated roles.

This is why I think High Dynamic Range Developers matter. By “HDR Dev”, I mean people with a wide field of interest and appetite for tackling awkward problems — people who can move between user needs, interface decisions, data, and delivery without panicking.

Within that definition, I see the “Design Engineer”: a web‑native subtype of the HDR Dev who treats the browser as their canvas.

• They hold a high bar and strong taste for the final experience, not just whether it “works”.
• They can empathise with users, and fold that empathy into flows, copy, and constraints.
• They can build real, running software quickly — not just mock‑ups.

A designer who can code. A coder who can design.

If the original Webmaster was a generalist out of necessity, the Design Engineer is a generalist on purpose — a deliberate, modern answer to the same question: can one person hold enough of the problem, the medium, and the stack to move things forward?

Why the Resurgence Matters Now

The resurgence of the webmaster isn’t just nostalgia. It sits at the intersection of a few currents:

• Teams are slowly warming to broader roles — “full‑stack” became normal; “design engineer” is following, for certain kinds of work.
• More people are valuing work that lives on its own sites again, and gravitating towards smaller, personal corners of the web.
• The tooling is better than it has ever been, which makes it realistic for one person to hold more of the arc from idea to production.

There are still limits. In teams building vast products — with complex domains and acute functionality — quality can become patchy if you spread design and product thinking thinly and nobody tends the overall coherence of the experience. A design engineer in the middle doesn’t replace deep specialists; some organisations genuinely need whole careers of research or security or infrastructure.

Even so, I think the direction of travel is clear. More roles will quietly ask for webmaster‑shaped skills, even if they hide behind other titles. The web isn’t going away any time soon — and as more of our lives happen inside it, the craft of building and tending small, vibrant corners of it matters more, not less.

An Invitation to the Webmasters in Hiding

If any of this resonates, you might already be a webmaster in hiding.

Maybe you’re a designer who can’t help but tinker with code, or an engineer who sketches flows, writes copy, and worries about how users respond to an onboarding email. Maybe you’ve been told, explicitly or implicitly, to pick a lane.

I know I’m romanticising the term “webmaster” a little. It’s a functional label — “who looks after this site?”. One of the many Tim Berners‑Lee’s little offerings to the world wide web. “Design engineer” is one of the labels that fits this shape today, and I like it, but I still have a soft spot for “developer” in its truest sense: someone who develops ideas into outcomes — messy, uncertain, human outcomes.

For me, arguing for the resurgence of the webmaster is mostly about permission. Permission to stop apologising for not fitting cleanly into “designer” or “developer” boxes. Permission to treat the web as a full‑stack medium to be designed for, not just a deployment target. And permission to be proud of having lots of quills for your bow, because someone still has to hold the whole thing in their head.

Calling myself a webmaster makes me feel quietly powerful, in all honesty. It probably doesn’t make sense for that title to show up on my LinkedIn, but it fits perfectly on my own weird little corner of the web — ideally while I eat pizza and listen to Metallica.