DEV Community: Jackie

We built a last mile for AI HTML live websites

Jackie — Mon, 20 Jul 2026 07:16:38 +0000

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

Open htmltowebsite.com
Paste a complete HTML document (or use a sample)
Glance at preflight
Publish
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:

Why every site gets its own origin (and why we abandoned path-based hosting)
Preflight — catch broken paths and leaked secrets before publish
Paste → unlisted URL — the anonymous publish path in detail
Keep control without an account — management tokens, versions, claim
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.

I Built a Static Website Publishing Tool for Beginners

Jackie — Sun, 19 Jul 2026 08:25:51 +0000

Recently, I built a static website publishing tool designed for complete beginners. You don’t need to understand servers or mess around with complicated commands. Just upload your HTML, CSS, images, and other files. A few seconds later, you’ll get a link that anyone can open.
I made this tool because many people can now create web pages with AI, but they still get stuck when it’s time to publish them online. Buying a server, configuring a domain, and setting up the environment can feel overwhelming.
I wanted to make publishing a website as easy as posting on social media: upload, confirm, and you’re done. It’s useful for portfolios, event pages, personal profiles, and temporary landing pages. The tool is still pretty simple, but the main workflow is ready, and I’ll keep improving it.

it is: htmltowebsite.com

We Rebuilt Our Online Photobooth Around the Print, Not the Share Card

Jackie — Fri, 10 Jul 2026 17:58:28 +0000

For a while, our online photobooth had the same conceptual problem as many creative tools: it treated the most decorated output as the main output.

The result looked polished, but it did not always feel like something that had come out of a real photo booth.

When we studied popular photobooth products and physical prints, the pattern became obvious. The primary artifact was usually simple: a borderless print or a strip with a very thin frame. The larger background, decorative objects, and social-media-friendly composition were a second layer around that artifact.

We had been collapsing those two layers into one.

That small observation changed how we designed the latest version of freephotobooth. Instead of adding more isolated effects, we rebuilt the system around two related outputs:

The original print — the strip, grid, or collage that should still look good when saved or printed by itself.
The share card — a coordinated 4:3 scene that stages the original print on a richer background for social sharing.

The share card is no longer the default product. It is the second mode.

A template is now a visual system

The word "template" can hide a lot of shortcuts. In many editors, changing a template simply swaps a background image or frame color. The photo layout remains the same, spacing remains the same, and decorations float independently from the composition.

That is not enough for a photobooth print.

Our new templates control a coordinated set of decisions:

print layout
outer margin and spacing between photos
frame thickness, color, and pattern
paper edge and depth
photo treatment and filter
decorations and attachments
typography and date treatment
the matching share-card background
the position and scale of the print inside that share card

This makes each template behave more like a small design system than a skin.

The camera page now shows the finished visual result before the user starts a session. The eye icon opens a deeper preview without adding labels or clutter to the picker.

The first Featured collection includes seven directions:

Modern Monogram uses oversized serif initials and an ivory editorial frame.
Sage Botanical pairs a quiet cream paper treatment with pressed leaves.
Studio Glam uses high-key monochrome photography and fashion-editorial spacing.
Purple Disco builds an ultraviolet party scene from mirror balls, stars, and neon details.
Seoul Minimal uses generous white space, blue accents, and a compact four-cut print.
Cherry Coquette combines blush paper, ribbons, pearls, and cherry-red details.
Classic Booth keeps the familiar clean strip for people who want the simplest result.

The goal was not to maximize decoration. It was to create a range of visual personalities while keeping the photo itself recognizable.

One look, four different formats

A template also needs to survive a layout change.

A narrow vertical strip and a wide postcard collage cannot use the same scale rules. Earlier versions exposed a common failure: when a grid or postcard was placed inside a share card, the content could become much too small because it inherited the positioning logic of a tall strip.

We now preview every template in four forms:

Original strip — one pose per row, closest to a physical booth print
Contact grid — a balanced two-column arrangement
Postcard collage — a lead image supported by smaller shots
Share card — the selected print staged on its coordinated background

The same Purple Disco direction adapts across four compositions. Each format has its own scale and spacing rather than squeezing one layout into another.

This preview is available before taking a photo. Clicking the eye icon opens the full template information, and each format can be inspected at a larger size.

That changed the role of the camera screen. It is no longer just a technical checkpoint for camera permission; it helps users imagine the result before the countdown begins.

The original print needed less margin, not more decoration

Another lesson came from looking at real booth strips.

Many contemporary products use either no outer margin or a very small one. Large side margins can make the photos feel timid and reduce the sense that the strip is a physical object. They become even more noticeable in grids, where every photo is already smaller.

So we added separate controls for:

outer paper margin
gaps between photos
thin photo borders
print edges and physical depth

The important part is that these controls are independent. Reducing the outer margin does not have to remove the visual separation between photos, and adding a paper edge does not have to change the photo crop.

These are small variables, but they decide whether the output feels like a designed print or a set of pictures inside a large empty card.

The library shows outcomes, not abstract swatches

Creative tools often represent templates with a color chip, icon, or empty frame. That makes the interface lighter, but it asks the user to perform the most difficult part mentally: imagining their photos inside the design.

Our template library now shows a real composed preview with example photography. Categories such as Featured, Clean, Cute, Party, Idol, and Seasonal make the collection easier to scan, while the preview remains the strongest signal.

The template library uses the same rendering rules as the editor, so choosing a card is a meaningful preview of the final output.

The same approach appears on the camera page: large images, no redundant visible labels, and a separate eye action for people who want the full details. The picker is meant to attract first and explain second.

Small interactions matter in a countdown product

The visual update also made us pay more attention to the moments between screens.

We added a restrained Japanese-inspired sound set: a light countdown cue, a crisp shutter, and a short completion sound. Audio stays optional and can be muted directly from the camera.

We also investigated the pauses that made the flow occasionally feel stuck.

There were several causes rather than one dramatic bug:

the camera page was loading the complete editor renderer just to draw template thumbnails
all template previews were rendering through Canvas during the first visit
the camera route could not be fully prefetched
the last photo was followed by a hard-coded delay before navigation
high-resolution camera frames were serialized synchronously into browser storage

The fixes were architectural rather than cosmetic. The camera now loads lightweight, pre-rendered 800×600 template images, while the full multi-format renderer is fetched only when someone opens a detailed preview. The route is statically generated and can be prefetched. The artificial post-capture delay is gone, and high-resolution sessions move through asynchronous IndexedDB storage.

In our production build, the initial client-side JavaScript associated with the booth route dropped from roughly 385 KB to 141 KB. More importantly, the flow now has a response ready for the user at each transition.

The photos still stay local

More visual richness should not require a heavier privacy model.

The camera, editor, templates, and export pipeline continue to work in the browser. A user can take photos, adjust the layout, switch templates, and download a PNG without creating an account. Camera photos are not automatically uploaded to our servers.

That constraint influences the product in useful ways. It encourages fast local rendering, reversible editing, and a workflow that does not stop to ask for identity before the user has made anything.

What we are building next

The new system gives us a better foundation for expanding the library. Future templates can introduce new compositions and physical treatments without turning every design into a one-off implementation.

We are especially interested in:

more Japanese and Korean photobooth directions
seasonal and event-specific packs
stronger print textures and physical finishes
more flexible captions and date systems
community-inspired template collections

But the principle will remain the same: the original print must work first. The share card should amplify it, not replace it.

Disclosure: I am building freephotobooth. This article describes the product decisions and implementation behind our latest template update.