DEV Community

Jackie
Jackie

Posted on

We built a last mile for AI HTML live websites

You know the loop.

Cursor (or Claude, or ChatGPT) spits out a full HTML page. It looks fine in the preview pane. Then someone asks for a link — a teammate, a client, a classmate — and the fun stops.

Do you open a Git repo for a one-pager? Spin up Netlify for something that shouldn't need a pipeline? Drop it on your production domain and hope cookies don't get weird? Paste it into a random bin and pray the relative images survive?

That gap — from "the model finished" to "here's a URL that actually works" — is what we built HtmlToWebsite for.

Not another site builder. Not another Git host. A last mile:

Preview → Check → Publish → Keep control

The job we're trying to finish

Most AI coding tools are great at generating browser-ready HTML. They're worse at the boring handover:

  • Will this break when someone else opens it?
  • Did we just publish a .env by accident?
  • Can I update the page tomorrow without changing the link?
  • Does this share my product login cookies if I host it under my main domain?

We kept seeing the same pattern: people treat "paste HTML somewhere" as a solved problem, then quietly burn an afternoon on paths, expiry, and "wait, who can still edit this?"

So the product is opinionated about one thing: you already have something the browser can run. We don't run npm install. We don't pretend to be SSR. We take static, browser-ready output and get it onto a real URL without making you adopt a whole platform.

What HtmlToWebsite actually does

1. Preview

Paste HTML, upload a single file, or (in the advanced path) point at a folder/ZIP locally. You get a sandboxed preview in the browser before anything goes public.

2. Check

Before publish, we run preflight on the release: broken relative assets, sensitive-looking files, "this looks like a source project, not a build output" smells. The goal is to fail before you send the link to someone who will politely tell you the logo is missing.

3. Publish

Anonymous publish is allowed. You get an unlisted URL on its own hostname — something like https://live-{slug}.htmltowebsite.com/ — not a path under our marketing site, and not under yours.

Guest sites currently keep for 7 days by default. The expiry is shown when you publish, not buried in a FAQ after the link dies mid-review.

4. Keep control

"No signup" shouldn't mean "fire and forget forever." Anonymous publishes get a one-time management token. Same public URL, new version. Claim into an account later if you want. Take it down when the review is over.

Who this is for

  • Vibe coders shipping demos out of Cursor
  • Frontend folks sharing a prototype without opening a repo
  • Anyone wiring an agent that should return a live URL, not a blob of HTML in chat
  • Teachers / workshop leads who need links that last a review week, not 45 minutes

Who this is not for (yet)

  • Apps that need a server, database, or SSR
  • Projects that only exist as npm run build with no output folder
  • Long-lived production sites with custom domains as the default path (that's a later upgrade story, not the V1 pitch)

If your release isn't browser-ready, fix that first. We're the last mile, not the whole highway.

How this differs from the usual options

Git deploy platforms are excellent when you already live in Git + CI. They're heavy when the artifact is "one HTML file the model just wrote."

Classic site builders want you to rebuild the page in their UI. You already have the HTML.

Pastebins / random HTML hosts get you a URL fast, then leave you with broken assets, unclear expiry, no real management story, and often a trust model that was never designed for "this might sit next to a product login."

We sit in the awkward middle on purpose: fast like a paste tool, careful like something that will hold client demos.

Try the boring happy path

  1. Open htmltowebsite.com
  2. Paste a complete HTML document (or use a sample)
  3. Glance at preflight
  4. Publish
  5. Open the live-… URL on your phone

If that works, you've already used the product. Everything else in this series is why the sharp edges are shaped the way they are.

What's next in this series

We'll go deeper, still around the product — not abstract blog filler:

  1. Why every site gets its own origin (and why we abandoned path-based hosting)
  2. Preflight — catch broken paths and leaked secrets before publish
  3. Paste → unlisted URL — the anonymous publish path in detail
  4. Keep control without an account — management tokens, versions, claim
  5. Agent publish protocol — Prompt URL + API so Cursor/Claude can ship the page they just wrote

If you've been stuck in the "model done, link missing" gap, that's the whole product. Start at the homepage; the rest of the series explains the bets underneath.

Top comments (0)