The one-click gap nobody was solving: why I built HTML Deployer
A few months ago I watched a marketer friend do something that made me wince.
She'd spent twenty minutes in ChatGPT crafting a landing page for a product launch. The copy was sharp, the layout was clean, the CTA button even had a nice little hover animation. She was proud of it — and she should have been.
Then she asked me: "Okay, how do I actually put this online?"
I told her to copy the code, create a repo, connect it to Netlify, wait for the build... and I watched her face fall somewhere around the word "repo." She closed the tab. That landing page never went live. Not because the idea was bad, not because the code was bad — because there was a wall between "I have HTML" and "I have a URL," and nobody had bothered to tear it down.
That's the moment this project actually started, even though I didn't write a single line of code that day.
The wall everyone pretends isn't there
Once I started paying attention, I saw the same wall everywhere. Not just with marketers — with freelancers sending demo links to clients, with solo founders trying to spin up a bio page between meetings, with small agencies juggling a dozen campaign microsites at once.
They could all generate a page in seconds. ChatGPT, Claude, Gemini — doesn't matter which. The AI part had gotten absurdly good. But turning that generated block of HTML into something with an actual link you could send someone? That still meant terminal commands, Git, hosting dashboards, FTP clients, or — worst of all — pinging a developer for something that should take thirty seconds.
The tools to create had leapt a decade ahead. The tools to ship were stuck in 2012. I couldn't stop thinking about how absurd that gap was.
First attempt: I tried to build a platform
My first instinct, embarrassingly, was to build Yet Another Hosting Platform. Upload your HTML, we host it, here's your link. I got a rough version working in a weekend and immediately hated it.
Here's the problem: the moment you build your own hosting platform, you're asking people to trust you with their site's uptime, forever. You're also locking them in — if they ever want to move to their own domain, their own Netlify account, their own infrastructure, tough luck. I'd just be recreating the exact kind of walled garden that made the original workflow so painful in the first place, just with a shinier wrapper.
I scrapped it. Worse than scrapping it — I sat on the idea for a couple of weeks not sure it was worth solving at all, since every direction I tried seemed to reintroduce the same friction I was trying to remove.
The unlock: don't move the destination, move the moment
The breakthrough wasn't technical, it was almost embarrassingly simple: the problem was never where people were hosting. Netlify is fine. GitHub Pages is fine. Plenty of people already have FTP access to hosting they're already paying for. The problem was the distance between "AI just finished generating this code" and "I am now doing something about it."
So instead of building a destination, I built a bridge that lives exactly where the pain happens — inside the AI chat itself.
That's the core idea behind HTML Deployer: a Chrome extension that watches ChatGPT, Claude, and Gemini conversations in real time, detects when an HTML code block shows up, and puts a Deploy button right next to it. No copy-paste. No new tab. No context switch. You're still looking at the conversation where the idea was born when you click the button that makes it real.
And on the other side of that button, you get to choose: Netlify, Vercel, GitHub Pages, your own FTP hosting, a self-hosted agent on your own server, or just a clean ZIP if you want to do it manually. No lock-in. If you already have hosting, use it. If you don't, get some in one click. The extension's job ends at "your HTML is now live" — it doesn't try to own what happens after.
Building the detection layer was the hard part
The UI is the easy 20%. The hard 80% was making detection actually reliable across three different chat interfaces that weren't designed to be scraped, that change their DOM structure without warning, and that sometimes render multiple code blocks in a single response.
A few things I had to solve along the way:
- Distinguishing an actual deployable HTML document from a stray
<div>snippet someone was showing for explanation, not deployment. - Handling streaming responses — code blocks that are still being typed out character by character shouldn't trigger a half-broken deploy button.
- Making the preview render instantly, across desktop, tablet, and mobile viewports, without spinning up a server, so people catch layout problems before the page is public instead of after.
- Being paranoid about credentials. FTP passwords and API tokens are exactly the kind of thing that should never touch a server I control. Everything happens client-side; nothing is stored on our infrastructure until the moment you hit Deploy, and even then it goes straight to your chosen destination.
That last point mattered more than any feature. Every person in this space — freelancer, agency, solo builder — has the same quiet fear sitting under the excitement: what if this breaks something for a client, or leaks a credential I'm responsible for? If the tool didn't earn trust on that front first, none of the convenience would matter.
What actually changed once it worked
The first time I generated a page in Claude, clicked Deploy, and got back a live HTTPS URL with a QR code before I'd even finished my coffee, it felt almost anticlimactic — which is exactly how a good tool should feel. Not magical. Just... no longer an obstacle.
That agency owner scenario I mentioned earlier — the one juggling a dozen campaign microsites — turned a 30-minute manual FTP routine into something closer to a minute, without changing the hosting they already trusted.
The actual lesson
If I had to compress this into one sentence for anyone building dev tools: the biggest wins aren't always in making something new possible — sometimes they're in deleting the five boring steps between "I already did the hard, creative part" and "this exists in the world now." AI didn't need another platform. It needed the wall between generation and publishing to just... not be there.
I still think about my friend closing that tab. That landing page never seeing daylight is a small thing, but it's the small thing multiplied across everyone who's ever built something good in an AI chat and then quietly given up at the last step. That's the gap HTML Deployer is trying to close — one Deploy button at a time.
If you're curious, it's a free Chrome extension and works with ChatGPT, Claude, and Gemini.
If you want to try it: HTML Deployer on the Chrome Web Store.
Would genuinely love to hear how other builders here are handling the "AI output → live thing" problem in their own stacks — I doubt HTML is the only place this wall exists.
Top comments (1)
Happy to answer questions, also here's the extension if you want to poke around:
chromewebstore.google.com/detail/g...