Listen
Essay
On my phone, I tap a button and a car arrives. I tap another and I have an apartment for the night. We've turned buttons on our screens into levers that move the real world. These buttons are as intuitive and easy to use as turning on a faucet in your home. Just like the faucet, there's a lot of plumbing behind the scenes to make them work.
But what if, every time you turned on your faucet, you had to crawl under the sink, stare at a mess of pipes, and reconnect things until the water came back?
Falling Into Trap Doors
That's what it feels like to build software on the web in the year 2026. Web development is riddled with trap doors between the act of creating and sharing a functional application. Here's what those trap doors tend to look like in practice:
- State sync: the UI works locally, but the moment you add a server, you're managing two sources of truth that can drift apart, conflict, or silently overwrite each other. Even on the front end alone, the moment you introduce a separate state object, you have two representations of the same data — the DOM and the model — that can fall out of sync in subtle, hard-to-debug ways.
- Schema lock-in: you're forced to commit to a data model while the interface is still evolving.
- Orchestration and scope creep: production behaves differently than local, dependencies drift, and "one small change" becomes a refactor.
- The "save my work" nightmare: a simple save feature turns into managing live sync, backups, autosave, and making sure the user doesn't get interrupted or lose work when they're just trying to write some text. It's layers of complex, invisible state that need to work flawlessly and almost never surface visible errors — because the moment they do, you've disrupted the flow you came to build.
- Deployment and ops: now you need migrations, updates, backups, monitoring.
There's a constant sense you're one mistake away from catastrophe. The day your certificate renewal fails or a background job silently dies, you realize shipping includes babysitting. You end up creating bash scripts to schedule deployments, backups, alerts, and downtime detection—because what you built is now a live system with moving parts, many of which you didn't write yourself.
The moment the trap door opens is usually the moment you hook your front-end to anything external—an API, a database, a login system, a deployment target.
The Seduction of a Puzzle
You stop working on a flat surface and start managing a knot of interconnected services and configurations. It feels puzzle-like and engrossing, like an entire world in itself. That's what makes it dangerous.
The temptation to go deeper into the puzzle can corrupt the entire creative process. Since we know how complicated operations and orchestration can be, why not get the complicated bit out of the way first? Our rational brain is captivated by this line of reasoning.
So we start by building the printing press instead of writing the book. If you find yourself 3 months deep into building a full-stack resume generator with user profiles and billing and deployment orchestration and you haven't created at least 20 resume template documents first, you need to stop and come back to the surface.
Creative Flow
Trap doors break creative flow. When you're in creative mode, slipping into debugging mode is always accidental. And it always disturbs your flow.
And yet it's so common in software development, it almost feels natural.
But when you're focused on making something for other people to experience, it's very important that you stay at the level of that experience. It's literally what you're building. It's like writing a story: if you get interrupted mid-thought, you lose the thread of the story and get sucked out of the moment you were building towards. It slips through your fingers like sand. This is where projects die.
When you find yourself losing your connection to the world you're building too often, you have to take a breath, bring your head above water, and stay focused no matter what.
You have to keep coming back to the questions that matter: what am I building and why? Do people understand it and want it? Does it feel like one cohesive experience?
That's the entire discipline of being a creative.
Journeyship
I'm more artist than engineer—obsessed with how people experience what I make. My craft lives at the intersection of people and screens.
Years ago, I built a side project called Journeyship: an animation scene builder where you control every pixel and every character. I worked on it in stolen moments: in a busy sandwich shop on my lunch break and a café in the evening, after work. I stitched it together piece by piece. It was complicated in a satisfying way: canvas drawing, caching, timelines, little animated pixel-art characters you'd build up pixel by pixel. I got it good enough that people wanted to use it.
Then I did what you do when you want to share a web project: I deployed it.
I installed Redis as my database, left a port open, and within a month my server got hacked. I still remember the moment I realized. I checked my email and saw an alert: "Monitor is down: Journeyship." Then, from Digital Ocean: "Networking disabled." I logged into my dashboard and saw my server was offline.
Everything was gone. Not just my work, everyone's work. Every animation people had made, every pixel they'd placed, erased because I'd misconfigured a firewall.
I felt broken. I couldn't bring myself to put the project back online. I'd lost something harder to recover than data: my confidence that I was capable of keeping something online.
Yes, there's a technical lesson here: put a firewall in front of your app and store backups off-site.
But the deeper lesson I took away is how easy it is for a creative person to wander across the divide between making an experience and operating a fragile machine on the open web.
The Divide
In web development, the surface is where most users' interactions happen. It's the part people touch and manipulate and see working. But the moment I try to share it with other people, the magic evaporates. Why?
There's a divide in the making of software.
Even when you're trying to make the simplest interface imaginable, you still get pulled into the behind-the-scenes machinery that makes it work. That's the plumbing.
It's messy. It's unpredictable. It sometimes requires reading book-lengths of documentation to configure correctly.
But that's not the worst part. The worst part is that it does not feel like one thing. Working on the plumbing feels like being pulled in 10 different directions at once. As you fix one thing, you break another thing in a totally unrelated system. The work stops being shaping an experience for your users and becomes operating complex, interconnected systems.
But I would argue that every layer below the surface exists only to serve the surface. And the moment it starts pulling you under instead of supporting you, something is broken.
[ THE EXPERIENCE ] (What you came to make) +-----------------------------+ | UI / Interaction Design | | HTML / CSS / JavaScript | | Canvas / WebGL / Components | | The actual idea | +=============================+ <-- The drop | Hosting, domains, SSL | into debug | Secrets, auth, permissions | mode | Databases, backups | | Security, updates, ops | | Build pipelines, config | +-----------------------------+ (Above: creation. Below: the stuff that pulls you under.)
Can we do better? Does publishing an interactive experience have to feel like building an entire CMS from scratch?
What if the surface you came to shape and the machinery behind it were flat, so they felt like one thing? What if we didn't have to choose between publishing a document and designing the editing controls that help us shape that very same document?
We could exist in both worlds simultaneously: we could shape the experience and give our users the power to shape that experience at the same time.
Surface-Level Artifacts
These questions led me to a different way of thinking about software artifacts. What if software had an all-encompassing, surface-level artifact? Something you could shape directly, share immediately, and let other people shape too? I'm talking about a specific kind of artifact: a malleable, shareable experience.
We've seen glimpses of this before. This idea isn't new.
Spreadsheets are the simplest proof. A Google Sheet is malleable, shareable software that can hold and process lots of data. Earlier tools like HyperCard and Flash had a similar feeling: the creative environment and the deployment environment were essentially the same. The artifact was the experience.
Webstrates is exploring it too: web pages that act as applications or documents depending on how they're used. Ink & Switch has been writing about malleable software and local-first software for years. The personal software community is building up real traction around this vision.
The idea is a kind of document that doesn't have a default editor, but includes its own editor in itself. It's your own personal file format, shaped by you, usable by others. It could allow anyone to create their own personal Photoshop or Google Sheets. This artifact is not a new Photoshop, it's a Photoshop-builder.
Malleable Documents
Good tools don't hide complexity behind a curtain, they eliminate the need for it. The surface is honest. If something looks like a checkbox, you can toggle it. If text looks editable, you can change it. With a surface-level artifact, the document is its own source of truth.
When you shape the document or add tools to the document that allow it to shape itself, you're shaping both, in the same place. You're editing the factory. And because both layers live together, you never leave the surface your customers interact with.
You can control where the toolbar lives, how it works, what its actions do, and what kind of output it produces. I think the most powerful place to be in the realm of personal software is going to be building the frameworks and primitives around how these malleable documents are produced. Built using native technology — probably mostly standalone HTML files — so anyone can view, access, share, and edit them. The web platform is already powerful enough; we don't need permission to make this happen today.
"We Already Have Frameworks"
We have frameworks, platforms, starter kits, one-click deploys and a thousand clever ways to flatten the stack. They handle authentication, migrations, caching, scaling—genuine complexity that matters for production software serving thousands of customers.
These tools already exist. Why do we need a new concept?
All of these one-stop-shop tools suffer from the same problem: they still pull you into the plumbing. You're still debugging configs and patching leaky abstractions. "One-click deploy" often means "one click after you've accepted an ecosystem's 30 pages of documentation."
I don't want to pretend like they're not useful. The plumbing exists for real reasons and the frameworks handle real complexity. Plenty of people will choose to maintain their own full-stack system because they want to maintain a unique and powerful system on the public internet. Frameworks and platforms will help protect their users' private information, help them build powerful integrations quickly, and guarantee uptime.
But if you're like me, when you finish building an experience, you're like an author who finally finished their novel. You don't want to be told you now have to construct a printing press. Dig into the source code when you choose to and when it really matters, not because you're forced to.
The Web We Want
When publishing requires thousands of lines of infrastructure code, the web gets fewer small, weird, personal projects. I miss the Geocities, Blogosphere, and StumbleUpon era, when everyone had their own malleable corner of the web. The web felt like what I thought billions of connected humans should feel like: chaotic and alive.
That magic has faded, but it doesn't have to die. I think it's time to bring back the malleable web, so we can copy, use, remix, and build on each others' work. To shape and be shaped alongside other people.
I believe, especially with the advent of competent LLMs, there's a wave of highly personalized, malleable software already being integrated into people's lives.
I'm building dozens of these tools myself: an ASCII HTML email editor, 2D hotseat video games, a Bluesky newsletter of my favorite topics. I want to build hundreds more. Personal software, built locally, shared casually: mentioned to a friend, passed along via thumb drive, growing organically instead of being displayed in a popup window.
That's the web I want to live in. A web where everything's malleable, so you can't help but become a creator.