Anti-plumbing: It turns out it takes lots of plumbing

1.5 years ago, I was going to "just launch". I even wrote a note to myself about it.

I had what most people would consider an MVP:

But I asked myself: would I pay for and use this product?

And the answer was a clear "no".

It was embarrassing, almost nonsensical, to launch without custom domains. Who would host even just a personal site on a platform without their own domain pointing to it?

So I added custom domains…

But then my projects — blog posts, experiments, example apps — started building up and I couldn't put them into folders.

So I built a dashboard with folders to organize my sites.

Then I tried using Hyperclay for my everyday work.

I ran into the same workflow over and over again:

  1. Make a malleable HTML file locally
  2. Open myapp.com/edit
  3. Paste the HTML into the code editor and save
  4. Refresh the live site to see my changes

It was a hassle.

I wasn't the only one who felt this way. Sandy Leach, one of my earliest paying users, emailed me:

"It would be great if I could just POST an HTML file to an endpoint while developing… Currently I'm doing the work in VS Code, testing on Hyperclay Local and then copying and pasting the code into the editor."

— Sandy Leach

Someone else on my mailing list put it even more bluntly when talking about their own personal workflow:

"I hate how I have to go back and forth between IDE and browser to persist changes and a lot of times I edit css or html in browser, but then forget that I have to put that in an IDE."

The workflow I really wanted — in order to stay in flow — was:

  1. Edit locally using my own tools
  2. Save locally
  3. See the changes on the internet

I asked Claude Code: "How hard would it be to build a cross-platform desktop app, a local version of the full Hyperclay platform?"

Unfortunately (or fortunately depending on your perspective), this was back a year ago when Claude Code didn't know how to respond to a simple question with a few words and would instead code up a full solution, touching dozens if not hundreds of files in the process.

I came back to my computer 20 min later to see that Claude had a fully working prototype of Hyperclay Local.

I was astounded.

That app became my daily driver. I have it running in the background constantly, even now.

It runs a local server so I can work on malleable HTML files even when I don't have internet, as if they're regular apps on my computer. And when it syncs my changes to the platform, all my live sites update.

It feels magical.

One of the first questions I got about Hyperclay Local was from Geoffrey Lambeth, who opened an issue on GitHub:

"Is it possible to create a new 'app' from scratch using Hyperclay Local? Or is the expected workflow to begin on the website?"

— Geoffrey Lambeth

It was a good question. The answer should obviously be yes — yes you can create a file locally and it will just auto sync to the platform.

Unfortunately, I hadn't built bi-directional sync yet.

So, I sat down that morning and started coding it up. It took me a couple weeks, but I ended up with a pretty robust system.

Around this time I launched OverType, an open source embeddable markdown editor, that's really just a textarea. A lot of you discovered me either through that project or through the HN launch of Hyperclay.

That HN launch happened kinda by accident. Someone saw the footer note on OverType

Built with the radical idea that sometimes dumb ideas work

Ready for another radical idea?

Let's remove every layer of the web application stack.

And they launched Hyperclay on HN without me knowing about it!

That was the first time a lot of people outside my circle saw Hyperclay. And the feedback changed my priorities. One HN commenter, BoppreH, wrote a description of Hyperclay so clear that I added it word-for-word to the homepage:

"Hyperclay is a NodeJS server and frontend JS library that allows HTML pages to update their DOM and then replace their own .html source with the updated version."

— BoppreH

I couldn't explain my own project as well as a stranger could after 10 minutes with it. That's the kind of thing that only happens when you put your work in front of other people.

Meanwhile, one of my early subscribers was the one who posted Hyperclay to HN, where it got 646 points. It had been too complex for his use case earlier on, but I think as the product grew he was starting to see the cohesive picture.

That same subscriber came back months later with a concrete use case:

"I want to publish a public roadmap of my project, where people can create new feature requests and upvote them in one column, and the rest of the advancement is managed by me entirely."

That's exactly the kind of thing I want Hyperclay to support — one person controls the app, but other people can interact with specific parts of it. So I added support for share links. These are Google Docs-like links that let you grant edit access to anyone who has the link.

But after I built that, I had to ask myself: can you effectively use share links without live collaboration?

So then I undertook a massive project that had brought me to my knees many times before.

Live sync.

I did a quick experiment built on top of idiomorph, the beautiful DOM syncing library. It worked well enough, but I needed something a little more robust for the messier HTML I was often working with. So I built my own library on top of it.

It works. As far as I can tell.

And suddenly, I had the ability to edit a file locally, see changes live sync to the internet, and to anyone with a share link.

This was a milestone. The first time I could compare Hyperclay to Google Docs and feel like the comparison was honest.

None of these features were on the original roadmap. Custom domains, the dashboard, the desktop app, live sync — all of them came from the same place: having people give feedback on the deployed product and tell me what it was missing.

That incomplete app that I almost launched 1.5 years ago — the one I would NOT have paid for — is the reason Hyperclay exists in its current form. That almost-launch made everything feel real. And suddenly I knew exactly what was missing. It kept me trudging over the giant mountain in front of me that I knew I didn't want to climb, but knew I had to anyways. Because the dev experience I WANTED was on the other side.

The people responding to my emails weren't just frontend developers. Gabrielle Black, a backend engineer, wrote me:

"The biggest road block for me is the persistence layer… I want something that is as bare bones as possible, easy to maintain, but still flexible enough for creative expression. Plus I need to upgrade my HTML skills and this seems a great way to do it."

— Gabrielle Black

She wants a personal blog. That email, and a lot of others like it, is why I added a $6/month Personal plan. Not everyone wants to start a business and create a bunch of multi-tenant apps or business websites. Some people just want a malleable corner of the web.

Now we come closer to today. And we have the file naming problem.

Syncing sites from the Hyperclay Local desktop app was my preferred way to develop. But hooking it up to the platform was genuinely annoying because each file's name had to be globally unique. Because each file claims its own subdomain.

If someone else already had blog.html, you couldn't sync your blog.html file to the platform. You'd have to rename your local file to something random just to get it online.

It even meant you couldn't have two files named demo.html in two different folders on your OWN computer if you expected them to sync to the platform.

This is a silly architecture.

It also made no sense why you'd get a limited number of malleable HTML files in your account. It's just a static site that we overwrite every once in a while. The storage cost for Hyperclay is near zero. The only thing that eats into our margins are subdomains and custom domains, and we were conflating "creating a file" with "claiming a domain."

I kept coming back to the idea that this should feel like Google Docs: creating a malleable HTML file should be light and easy. Not some major decision or multi-step process.

So I spent the past several weeks of March 2026 rearchitecting the entire system. Files are now scoped to your account, just like in a filesystem. You can have blog.html and so can anyone else. There's no cap on the number of these files, they're unlimited. Subdomains are a separate, optional upgrade you can claim when you want a short, nice URL.

It was one of the biggest architectural and user-facing changes to the platform since launch. But it had to happen. The old model was fighting against the clarity of the vision.

The username-namespaced change made file creation feel light. But syncing was still fragile. Two separate pipelines — sites and uploads — each with their own quirks, and folders handled badly by both. Rename a folder and the system might cascade-delete everything inside it on the server. Delete an upload while offline and it would come back on reconnect.

Over the first few weeks of April 2026, I rebuilt all of it as one coherent system. It's even less code than before because now sites, uploads, and folders all use the same pipeline. It's the kind of work that's invisible if it goes well. Files and folders just move, delete, and rename without surprises.

This is the kind of system I wanted from the beginning, but I only discovered what it should look like by building the wrong version first.

We're only 20% towards my vision of building truly invisible software. But that's a lot better than 5%, which is where I was at 1.5 years ago. And for the first time, it feels like what I've built is one coherent tool, not just a prototype or side project.

I hope you enjoy using it.

Happy hacking,

David

P.S. Two weeks ago, one of my brothers-in-law asked me: "Hey, do you know a way to send someone an HTML file they can fill out and send back to me?" A simple question that brought me back to the foundational vision of Hyperclay. It sent me down a research rabbit hole that I'm still exploring. In the next blog post I hope to explore it further.