Build your own kingdom

Last week I built share-html, a small tool that publishes Claude's HTML pages to a link anyone can open. A few days later I found that Claude's own artifacts now do all of it: public links with no sign-in, the same URL when you republish, and comments when you share inside your team.

So I deleted it. It took two changes: remove the skill, remove one rule from my CLAUDE.md.

It cost me almost nothing

To be clear, this wasn't a loss. It was one evening, a 100-line shell script and a blog post. I learned some things about Cloudflare along the way, and for a few days it solved a real problem for me. Then the problem went away, which is the best outcome.

But it made something concrete for me that I'd only thought about in the abstract.

It's the same story at every size

Mine was a tiny version of something that's happening to whole companies right now. Someone notices a gap in what one of the big AI labs ships. They build a product to fill it. Customers come, because the gap is real. Then the lab ships an update, and the gap is gone.

Nothing about that is unfair. The gap was always in someone else's product, and they were always going to close it once enough people needed it. My tool existed because artifacts were missing something. That was also the reason it was going to stop being needed.

What's new is the speed. These companies ship every week, and every release touches more of the surface around them. Whatever sits right next to the model is in the path.

Build your own kingdom

The lesson I keep coming back to: it's better to build your own kingdom than to build in someone else's.

share-html lived entirely inside someone else's kingdom. Its whole reason to exist was a missing feature in their product, and they decide what's in their product.

I don't fully know what building your own kingdom means yet. My first guesses:

• Own the problem, not the gap. Fill a gap in a platform and the platform owns your roadmap. Solve a problem your customers have, and the platform is just a tool you use to solve it.
• Own something they won't build. The labs build things that millions of people need. Something that only matters to a specific industry, workflow or group of people is much less likely to show up in a release note.
• Make their updates help you. If a better model makes your product better, you're building on them. If a better model makes your product unnecessary, you're building in their way.

I'm not sure these are right, and I'm sure they're not complete. But next time I start building something, I'll ask one question first: if the company this sits on ships this next week, what do I still have?

For share-html, the honest answer was: nothing, and that was fine. For anything bigger, I want a better answer than that.