DEV Community: jaxxchen

I Made a Web Page with AI. The Hard Part Was Giving It a URL.

jaxxchen — Sun, 02 Aug 2026 13:25:51 +0000

Disclosure: FolioDrop is my product. I am sharing this workflow and its limits so other people can decide whether a one-file publishing step fits their AI-made work.

I thought the hard part of making a small website with AI would be getting the HTML right.

It wasn't.

The awkward part came after the page looked good.

I had a finished HTML artifact, but it was still trapped in a conversation, a local file, or an editor preview. A client could not open file:///.... A recruiter did not need my repository. A friend did not want a deployment tutorial before seeing a tiny experiment.

The real question became:

What is the smallest reliable step between “the AI made this” and “here is a link you can open”?

The workflow I wanted

For a small, finished web artifact, I wanted five things:

Keep the AI-generated HTML intact.
Get a browser-ready HTTPS URL.
Share the result without explaining my local setup.
Keep enough source context to remember where it came from.
Collect the work somewhere instead of losing it when the chat ended.

That is the narrow job FolioDrop is designed for. It is not a replacement for a deployment platform. It is a post-generation handoff for one complete HTML document.

What counts as a “complete HTML document”?

The page should be self-contained enough to open as a page. Inline CSS and inline JavaScript are fine. External images, fonts, or scripts can work when they remain reachable over HTTPS.

The boundary matters:

A single HTML export: a good fit.
A small interactive prototype in one file: a good fit.
A multi-file React or Next.js app: use a normal deployment platform.
A project that depends on a local folder or file:/// asset: fix the asset boundary first.

The product page states this plainly, which is useful. A tool is easier to trust when it tells you what it does not handle.

Three ways to start

The current FolioDrop surface exposes three paths:

1. Ask the AI assistant to publish

The AI-publish path uses the remote MCP endpoint:

Connect FolioDrop, then turn my AI creations into shareable links.
https://foliodrop.app/mcp

The exact authorization step depends on the AI client and the account or workspace settings. The important product idea is that publishing happens after generation, while the artifact is still in context.

2. Upload the complete file

This is the comfortable fallback when the assistant cannot connect. Choose one .html or .htm file, then generate the share link.

3. Paste the complete page

This is useful when the AI returned code in a conversation and there is no convenient local file yet. Paste the complete document, not a fragment that depends on a hidden build step.

The result should feel like a handoff, not a file dump

The goal is not just “some hosting exists.” The person receiving the link should be able to open the page and understand what they are looking at.

FolioDrop's product language is built around a shareable work, source context, visibility, and a folio surface. That is a different mental model from dropping an HTML file into a random folder and forgetting it.

I also verified a real Xin'gang Village case set in the FolioDrop workspace. The strongest examples are a value introduction, a planning presentation, and a client-review operations and budget proposal. They show the useful range of AI-made work: product thinking, high-fidelity communication, and a stakeholder-ready deliverable.

Why this matters for AI-made work

AI makes it cheap to create many small things:

a landing-page experiment;
a visual interaction study;
a product concept for a client conversation;
a portfolio piece for an interview;
a tiny calculator or browser tool;
a themed page that is too small to deserve a full repository.

The cheaper creation becomes, the easier it is to lose the result. The missing layer is not always more generation. Sometimes it is delivery, context, and memory.

My rule of thumb

Use a full deployment platform when the project needs a build, multiple files, a server, environment variables, a custom domain, or a long-lived production workflow.

Use a one-file publishing flow when the artifact is already complete and the next job is to show it to somebody.

That distinction kept my tool choice simple:

Build wherever the work needs to be built. Publish the finished one-file artifact wherever it is easiest to share and remember.

If you make small web experiments with AI, what do you do with the HTML after the model says it is finished?

Canonical links: FolioDrop home, publish HTML online, Xin'gang Village case set.

AI can generate HTML. Publishing it is still weirdly annoying.

jaxxchen — Thu, 28 May 2026 16:17:05 +0000

AI tools are now pretty good at making complete HTML artifacts:

a small portfolio page
a product one-pager
a pitch deck in HTML
a resume
a visual prototype
a client preview

But after the model gives you the HTML, there is still an awkward last step:

How do I turn this into a real URL I can send to someone?

For developers, the normal answer is GitHub Pages, Netlify, Vercel, Cloudflare Pages, or an object-store flow. Those are good tools. But they are also a lot of ceremony when the artifact is just one finished HTML file.

For non-developers, the gap is even worse. They can ask ChatGPT to create a nice HTML page, but the result often stays trapped in a chat window or a local file.

The narrow problem

The use case I wanted to solve was not "deploy a website."

It was:

Publish one complete AI-generated HTML document as a shareable link.

That means:

no repo required
no build step
no ZIP project
no framework deployment
no DNS setup
optional access-key sharing for private previews

So I built FolioDrop around that narrow contract.

What FolioDrop does

FolioDrop accepts one complete single-file HTML document and returns a real URL.

It is intentionally smaller than a static host:

Paste or upload one HTML work manually.
Publish from an AI tool through MCP or OpenAPI.
Save public works into a lightweight personal folio.
Keep access-key protected works unlisted.
Keep individual shared work routes out of search indexing.

The important boundary: FolioDrop is not a replacement for Vercel, Netlify, GitHub Pages, or Cloudflare Pages. If your project needs multiple files, a framework, a custom domain, or long-term production hosting, those tools are a better fit.

The comparison is here: FolioDrop vs static hosting.

Why MCP/OpenAPI matters here

The manual flow is useful, but the more interesting flow is agent-native publishing.

If an AI host can call a publish tool, the user can ask for:

Make this into a single-file HTML page and publish it.

The agent can then:

generate the HTML
validate that it is a complete document
call the publishing endpoint
return a URL

FolioDrop exposes:

MCP endpoint: https://foliodrop.app/mcp
public MCP config: https://foliodrop.app/api/ai/mcp-config.json
OpenAPI description: https://foliodrop.app/api/ai/openapi.json

I also packaged the publishing workflow as an open GitHub skill:

github.com/jaxxchen003/foliodrop-publisher-skill

That repo includes a single-file HTML validator and templates for decks, resumes, product one-pagers, emails, and portfolio case studies.

The publishing contract

The current contract is deliberately strict:

include <!doctype html>
include <html>, <head>, and <body>
inline CSS in <style>
inline JavaScript only when needed
use public HTTPS URLs for external images or fonts
do not include tokens, secrets, passwords, or local file paths

This constraint keeps the product predictable. It also makes the output easier for AI agents to reason about.

What I learned

The hard part was not generating HTML. The hard part was making the last mile boring:

return a stable URL
avoid leaking access keys
avoid indexing private previews
make deletion and expiry clear
keep the product boundary honest
give agents a structured way to publish without putting secrets into prompts

I wrote up two answer pages for the common questions:

The product is small on purpose. If the work is a real website, use a real static host. If the work is one complete AI-made HTML artifact and you just need a link, that is the gap FolioDrop is trying to close.