DEV Community

jaxxchen
jaxxchen

Posted on

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

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:

  1. Keep the AI-generated HTML intact.
  2. Get a browser-ready HTTPS URL.
  3. Share the result without explaining my local setup.
  4. Keep enough source context to remember where it came from.
  5. 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
Enter fullscreen mode Exit fullscreen mode

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.
The FolioDrop upload state
The FolioDrop paste state

Top comments (0)