DEV Community: Julie Do

The one-click gap nobody was solving: why I built HTML Deployer

Julie Do — Fri, 03 Jul 2026 08:31:21 +0000

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.

webdev #ai #chrome #productivity

I built a Chrome extension to deploy AI-generated HTML in one click

Julie Do — Tue, 16 Jun 2026 08:02:09 +0000

The problem I kept running into

Every time I used Claude or ChatGPT to build a quick landing page or a
microsite prototype, I hit the same wall at the end.

The HTML looked great. But getting it live meant:

Copy the code out of the chat window
Create a new project on Netlify (or push to a GitHub repo)
Wait for the deploy pipeline
Share the link

For a developer, that's maybe 5 minutes of boring overhead. But for a marketer or no-code builder? It might as well be a locked door.

And even for me — when I'm doing it 10+ times a week across small
client projects — those 5-minute tasks add up fast.

What I built

HTML Deployer is a Chrome extension that sits inside your AI chat session (ChatGPT, Claude, Gemini) and adds a Deploy button directly next to every HTML code block.

Click it → preview the page on desktop, tablet and mobile → choose
where to publish → done.

No copy-paste. No tab switching. No terminal.

The four deploy targets

I wanted to avoid locking users into a single platform. So the
extension currently supports:

Target	Best for
Netlify	Free CDN, HTTPS, custom domain — easiest for most people
Vercel	Fast preview URLs, zero config
GitHub Pages	Version-controlled static hosting, free forever
FTP / cPanel	Your own shared hosting — most agencies already have this
Self-hosted agent	A tiny PHP file on your server, no FTP credentials stored in the extension
ZIP export	Download and upload manually — maximum flexibility

The self-hosted option was a deliberate design choice. A lot of
freelancers and small agencies have existing hosting accounts they're paying for. There was no reason to force them onto Netlify just because it's the path of least resistance.

How it actually works (technical overview)

When the extension loads on a supported AI page, it uses a
MutationObserver to watch for new <code> blocks being rendered in the DOM. When it detects a block that looks like an HTML document (it checks for <!DOCTYPE, <html>, or <body> tags), it injects asmall Deploy button into the parent element.

// Simplified detection logic
const observer = new MutationObserver(() => {
  document.querySelectorAll('pre code').forEach(block => {
    if (isHTMLDocument(block.textContent) && !block.dataset.hdInjected) {
      injectDeployButton(block);
      block.dataset.hdInjected = 'true';
    }
  });
});

observer.observe(document.body, { childList: true, subtree: true });

For the preview, the extension renders the HTML in a sandboxed iframeinside a side panel. It uses CSS transforms to simulate three viewport sizes without making any network requests — everything stays local.

For Netlify and GitHub deploys, the extension uses their respective
REST APIs. Credentials are stored in Chrome's storage.local (not
synced across devices, not sent to our servers).

For FTP deploys, the extension talks to a small backend proxy (because browsers can't open raw TCP connections). The FTP credentials are encrypted in transit and not logged or stored on our side.

The self-host option explained

Some users — particularly agencies with client hosting accounts — don't want to enter FTP credentials into a browser extension at all. That's a completely reasonable security concern.

The self-hosted mode works like this:

You download a single agent.php file (~30 lines)
You upload it to your own server
You point the extension at your server URL + a secret token you set

The extension sends the HTML payload to your own server, which writes the file to disk. Your FTP credentials never leave your server. The extension only knows the public URL of the agent.

<?php
// Simplified agent.php
$token = 'your-secret-token-here';
if ($_SERVER['REQUEST_METHOD'] !== 'POST') exit;
if ($_POST['token'] !== $token) http_response_code(403) and exit;

$filename = basename($_POST['filename'] ?? 'index.html');
$html = $_POST['html'] ?? '';
file_put_contents(__DIR__ . '/' . $filename, $html);

echo json_encode(['url' => 'https://' . $_SERVER['HTTP_HOST'] . '/' . $filename]);

Not fancy, but effective.

What the workflow actually looks like

Here's a typical session for a freelancer building a landing page for a client:

Open Claude
Ask it to build a landing page with a specific offer and CTA
HTML Deployer auto-detects the code block
Click the Deploy button in the sidebar
Preview looks good on mobile — approve
Select Netlify, click Deploy
Get a live URL + QR code in about 8 seconds
Send the URL to the client for feedback

The whole thing from "AI generates the code" to "client has a link" is under 2 minutes. Previously, that same flow was 10–15 minutes of
switching between tabs, copying code, creating Netlify projects, etc.

What I learned building this

MutationObserver is your friend — but also your enemy.
AI chat interfaces re-render constantly. ChatGPT in particular
re-renders code blocks multiple times as streaming completes. I had to add debouncing and a dataset flag to avoid injecting the button multiple times into the same block.

Browser storage is trickier than it looks.
chrome.storage.local has a 5MB limit per item. For an extension that stores deploy history, that fills up faster than you'd expect if someone is deploying large HTML files with embedded base64 images. I had to add a cleanup routine that prunes old history entries.

Users are more security-conscious than I expected.
The most common first question was: "Does this store my FTP
credentials?" — not "How does the preview work?". That pushed me to build the self-host option earlier than planned, and to make the
security model explicit in the onboarding flow.

Try it

HTML Deployer is free to install on Chrome Web Store:
→ Install HTML Deployer

If you have a use case that doesn't fit the current deploy targets, or you find a bug, feel free to drop a comment below or reach out.

Would genuinely love to hear how other builders are handling the
"AI output → live page" gap in their workflows.