DEV Community: Julie Do

What Nobody Shows You in an "AI Built My Website" Demo

Julie Do — Fri, 24 Jul 2026 06:48:16 +0000

It's been a rough week, not gonna lie. I spent three days debugging a Chrome extension update that Google's review team flagged for "requesting unnecessary permissions" — turns out it was a single leftover activeTab scope I forgot to remove after a refactor two versions ago. Three days, one line.

On top of that, a user emailed me asking why their FTP deploy "silently did nothing," and it took me an embarrassingly long time to realize their hosting provider was rate-limiting anonymous connections from datacenter IPs — not something I'd ever hit testing locally.

Anyway. Not the week I planned. But it did remind me of something I've been meaning to write about.

Every "I built a website with AI" demo skips the same 10 seconds

You've seen the demo a hundred times. Someone opens ChatGPT or Claude, types a prompt, a beautiful landing page appears... and then the video just ends. Cut to a live URL. Cut to "look, it's deployed!"

Nobody shows what happens in between.

That gap gets treated like it's the hard part — like there's some serious infrastructure decision happening off-screen. Framework choice. Server config. DevOps knowledge you're supposed to already have.

There isn't. That gap is maybe 80 lines of very boring code.

What's actually happening in that gap

Strip away the marketing and "AI-generated site → live URL" is three unglamorous steps:

Step 1: Find the HTML.
The AI's response is just text on a page. If it's ChatGPT, Claude, or Gemini, that text is sitting in a <pre><code> block in the DOM, updating as it streams in.

const observer = new MutationObserver(() => {
  clearTimeout(debounceTimer);
  debounceTimer = setTimeout(scanForHtmlBlocks, 600);
});
observer.observe(document.body, { childList: true, subtree: true });

function scanForHtmlBlocks() {
  return [...document.querySelectorAll('pre code')]
    .filter(el => /<!DOCTYPE|<html/i.test(el.textContent));
}

That's it. No parsing library. You're just waiting for the DOM to stop mutating, then checking if a code block's text looks like an HTML document.

Step 2: Ask a hosting API to put it somewhere.
Netlify, Vercel, and GitHub Pages all expose plain HTTP APIs for exactly this. A deploy is, at its core, a POST request with your file attached and a token in the header. There's no magic — it's the same shape of request you'd write to hit any REST API.

await fetch('https://api.netlify.com/api/v1/sites', {
  method: 'POST',
  headers: { Authorization: `Bearer ${token}` },
  body: zipBlobOf(html)
});

Step 3: Get a URL back.
The API responds with a live URL. That's the "magic" part of the demo — it's a JSON field.

That's genuinely the whole gap. Nobody shows it because there's nothing to show — it's a fetch call, not a feature.

Where it actually gets annoying

Here's the part that isn't trivial, and it's not the part anyone talks about:

The DOM you're watching belongs to someone else's frontend, and it changes without warning. ChatGPT, Claude, and Gemini all ship UI updates constantly, and none of them owe you a stable class name. Matching structurally (<!DOCTYPE, <html>) instead of by CSS class is the only thing that's survived more than a few weeks for me.
A single AI response can contain more than one code block — the full page, plus a CSS tweak explained separately. Grabbing "the first <pre> tag" picks the wrong one more often than you'd expect.
The moment you preview untrusted HTML before deploying it, you're rendering someone else's <script> tags. An iframe with a locked-down sandbox attribute is doing more real work in this whole pipeline than the deploy call itself.
And the question people actually ask first isn't "which host do you support" — it's "where does my FTP password go." That one shapes the architecture more than anything else on this list.

None of this needs a framework. It needs a MutationObserver, a fetch call, and paying attention to the two or three things above that actually bite you in production.

Why I'm telling you this

I ended up building all of the above into a Chrome extension called HTML Deployer — it sits on top of ChatGPT/Claude/Gemini, does the detection + preview + deploy steps above, and lets you push to Netlify, Vercel, GitHub Pages, FTP, or your own self-hosted endpoint, with a ZIP export if you'd rather do it manually.

But I'd rather you walk away from this post knowing how the gap works than just knowing the tool exists. If you've built something similar and hit a different wall than the ones above, I'd genuinely like to hear about it in the comments.

5 Things I Learned Building a Chrome Extension That Watches ChatGPT, Claude & Gemini

Julie Do — Thu, 16 Jul 2026 09:43:05 +0000

I spent the last few months building a Chrome extension that detects HTML code blocks inside ChatGPT, Claude, and Gemini and lets you deploy them straight to a live URL. The "deploy" part turned out to be the easy 20%. The hard 80% was reliably watching three completely different, constantly-changing chat UIs without breaking every other week.

Here's what actually taught me something.

1. `MutationObserver` is non-negotiable, but it will still lie to you

None of these chat apps render the full response at once — they stream tokens in, which means the DOM you're watching is incomplete almost every time your observer fires.

My first version tried to detect a finished <pre><code> block the moment it appeared. Result: I was grabbing HTML mid-stream, cut off halfway through a <div>.

What actually worked was debouncing on DOM stability instead of DOM presence:

let debounceTimer;
const observer = new MutationObserver(() => {
  clearTimeout(debounceTimer);
  debounceTimer = setTimeout(scanForCodeBlocks, 600);
});
observer.observe(document.body, { childList: true, subtree: true });

600ms of "nothing changed" turned out to be a much more reliable signal than "the tag now exists." Not elegant, but it works across all three sites' streaming speeds.

2. Every AI chat UI restructures its DOM without telling you

ChatGPT, Claude, and Gemini all ship frequent frontend updates, and none of them are obligated to keep a stable class name for you to hook into. I initially selected code blocks by class name (.language-html, .hljs, etc.) and had selectors silently break in production within two weeks of launch.

What's held up better: matching on structural patterns instead of class names — a <pre> containing a <code> whose text content starts with <!DOCTYPE or <html. It's slower to write the first time, but it doesn't care what CSS class the framework decided to use this month.

3. "Detect the code" is easy. "Detect the right code" is the actual problem

A single AI response can contain multiple code blocks — a full HTML page, a CSS snippet the model explains separately, a JS fix suggested afterward. Grabbing "the first <pre> tag" is wrong more often than you'd think.

I ended up scoring candidate blocks instead of just taking the first match: presence of <!DOCTYPE> or <html> scores highest, presence of <head>/<body> scores next, and blocks under ~50 characters get discarded outright (usually just an inline example, not a real page). It's not perfect, but it cut false positives dramatically.

4. Client-side preview needs a real sandbox, not just an iframe with `srcdoc`

My first preview implementation just dumped the extracted HTML into an iframe with srcdoc. It worked until someone's AI-generated page included a <script> that tried to reach window.parent — completely benign in their case, but it's exactly the kind of thing you don't want silently allowed in an extension with content-script access to the current page.

<iframe
  sandbox="allow-scripts allow-same-origin"
  srcdoc="...">
</iframe>

Locking sandbox down explicitly, and being deliberate about which permissions you grant back, is one of those five-minute fixes that matters a lot more than it looks like it does.

5. The credential question is the one users actually ask first

I expected the first questions after launch to be about which hosts were supported. Instead, almost everyone's first question was some version of: "where does my FTP password go?"

That pushed me toward a design I'd recommend to anyone building a browser extension that touches any kind of credential:

Never route credentials through your own backend if you don't have to.
For FTP specifically, everything happens directly between the extension and the host — I don't sit in the middle.
For self-hosted setups, I added a lightweight PHP "agent" script users drop on their own server, which accepts authenticated uploads without ever storing an FTP password inside the extension's storage at all.

None of this is exotic security engineering. But "where does my password go" is apparently the single highest-trust-impacting sentence you can answer clearly in your docs.

The extension this came out of is called HTML Deployer — it takes the HTML that ChatGPT/Claude/Gemini generate and pushes it to Netlify, GitHub Pages, FTP, or a self-hosted target, with a preview step in between. If you've hit similar DOM-stability or sandboxing problems building on top of these chat UIs, I'd genuinely like to compare notes in the comments.

Stop Copy-Pasting AI HTML Into FTP Clients

Julie Do — Thu, 09 Jul 2026 07:30:05 +0000

The workflow that was quietly wasting my time

Here's a pattern I bet a lot of you know well:

You open ChatGPT, Claude, or Gemini. You ask for a landing page, a demo, a quick prototype for a client. Thirty seconds later you've got a full HTML file — styled, responsive, ready to look at.

And then... nothing. It just sits there in a chat window.

To actually turn that into something you can send a client or drop into a browser tab, I was doing this, every single time:

Copy the code block out of the chat
Paste it into a new file in my editor
Save it as index.html
Either zip it and drag it into Netlify's dashboard, or open FileZilla, connect to FTP, and upload it to the right folder
Go back, realize I forgot to check how it looks on mobile
Repeat steps 1–4 after every small copy tweak

None of these steps are hard. That's exactly the problem — they're not hard, they're just friction, and friction is what kills momentum on small jobs. If you build landing pages, demos, or client prototypes regularly, this "last mile" between AI output and a live URL adds up to a surprising amount of dead time across a month.

I tried a few workarounds first:

CodePen / JSFiddle — great for sharing a snippet, but not a real deployable page (no custom domain, no proper hosting, weird for client-facing work).
netlify deploy via CLI — fast once it's set up, but it means dropping into a terminal every time, which breaks flow when you're mid-conversation with an AI tool.
A local script that watches a folder and pushes to GitHub Pages — worked, but was one more repo to maintain, and useless the moment I was on a different machine.

None of it solved the actual bottleneck: getting from "the AI just wrote this HTML" to "here's a live link" without leaving the browser tab I was already in.

So I built a Chrome extension for it: HTML Deployer

The idea is simple: the extension watches the page while you're in ChatGPT, Claude, or Gemini, detects HTML code blocks as they're generated, and gives you a deploy panel right there — no copy, no paste, no context switch.

How it works, technically

1. Detection
A content script scans the DOM of supported AI chat interfaces for <pre><code> blocks that look like HTML (<!DOCTYPE, <html>, or a recognizable structure). It handles multiple code blocks on the same page, so if the model gives you three revisions in a thread, you can pick the one you want.

2. Preview before you ship anything
Before any network call happens, the extension renders the extracted HTML in an isolated preview — desktop, tablet, and mobile viewports side by side. This runs entirely client-side (no server round-trip), so you catch a broken layout before it's public instead of after a client opens the link.

3. Deploy targets — deliberately not locked to one host
This was the part I cared about most. A lot of "one-click deploy" tools quietly lock you into their own hosting. I didn't want that, so HTML Deployer supports:

Target	What happens under the hood
Netlify	Uses Netlify's deploy API with your token, gives you HTTPS + CDN instantly
Vercel	Same idea, Vercel's edge network
GitHub Pages	Commits the file to a repo/branch you choose — version-controlled by default
FTP	Straight upload to any shared hosting you already pay for (cPanel, WHM, etc.)
Self-hosted (Host Agent)	A tiny PHP script you drop on your own server that accepts authenticated uploads — so you never have to store FTP credentials inside a browser extension
ZIP export	If you'd rather upload manually, or hand the file to someone else, you get a clean `.zip` with no dependency on the extension at all

That last point matters for a dev audience specifically: your HTML is processed locally in the browser. It's only sent anywhere the moment you click Deploy, and only to the destination you picked. Nothing sits on a third-party server "just in case."

4. Instant feedback loop
On successful deploy you get a live URL and an auto-generated QR code — handy for testing on your phone or dropping straight into a client Slack message.

Who this is actually for

I'm not going to pretend this is groundbreaking distributed-systems engineering. It's a focused tool for a specific, repetitive gap:

Marketers / no-code builders / solo founders who use AI to generate landing pages and don't want to touch a terminal at all.
Freelancers and independent devs who ship small static sites for clients constantly and are tired of the same five manual steps for every demo.
Small agencies running multiple microsites/campaign pages who want a lighter, less error-prone alternative to "junior opens FileZilla and hopes for the best."

If your deploys already involve CI/CD pipelines, this isn't trying to replace that — it's for the disposable stuff: prototypes, one-off landing pages, demos, things that don't need a full pipeline but still need to be a real, shareable URL.

What I'd genuinely like feedback on

Anyone using a similar "watch the AI chat, extract the artifact" pattern for other file types (I'm curious if this generalizes beyond HTML)?
If you've built self-host agents like this before, I'd love to compare notes on keeping credential handling minimal — right now the PHP agent approach avoids storing FTP creds in the extension at all, but I'm open to better patterns.
Anything from the FTP/cPanel world that would trip this up on more unusual hosting setups?

The extension is live on the Chrome Web Store if you want to poke at it — happy to answer anything about the implementation in the comments.

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.

DEV Community: Julie Do

What Nobody Shows You in an "AI Built My Website" Demo

Every "I built a website with AI" demo skips the same 10 seconds

What's actually happening in that gap

Where it actually gets annoying

Why I'm telling you this

5 Things I Learned Building a Chrome Extension That Watches ChatGPT, Claude & Gemini

1. MutationObserver is non-negotiable, but it will still lie to you

2. Every AI chat UI restructures its DOM without telling you

3. "Detect the code" is easy. "Detect the right code" is the actual problem

4. Client-side preview needs a real sandbox, not just an iframe with srcdoc

5. The credential question is the one users actually ask first

Stop Copy-Pasting AI HTML Into FTP Clients

The workflow that was quietly wasting my time

So I built a Chrome extension for it: HTML Deployer

How it works, technically

Who this is actually for

What I'd genuinely like feedback on

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

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

The wall everyone pretends isn't there

First attempt: I tried to build a platform

The unlock: don't move the destination, move the moment

Building the detection layer was the hard part

What actually changed once it worked

The actual lesson

webdev #ai #chrome #productivity

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

The problem I kept running into

What I built

The four deploy targets

How it actually works (technical overview)

The self-host option explained

What the workflow actually looks like

What I learned building this

Try it

1. `MutationObserver` is non-negotiable, but it will still lie to you

4. Client-side preview needs a real sandbox, not just an iframe with `srcdoc`