Building by prompting removed the slow part. What is left is the distance between something that works locally and something a person can open, and that distance is where most of these projects quietly end.
This guide covers what a page can carry, where the line is, and iterating without breaking the link.
A page carries more than people expect
If it runs in a browser and does not need a secret, it is a page.
Calculators, quoting tools, converters, checklists, dashboards over data that does not change, visualisations, games, prototypes, forms that post somewhere else. All of these are one file.
That file needs no account, no build, no deployment pipeline and no runtime. It works offline. It can be emailed, though it should not be. Put it at an address and anyone can use it.
Most of what gets built by prompting falls entirely inside this, and the instinct to reach for infrastructure is usually the thing that stalls it.
Where the line is
Three things genuinely need a server.
A secret. Any key in a page is readable by anyone who opens it. If a service requires a key that must stay private, something has to sit between the page and that service.
Shared changing state. Two people seeing the same updating data means something central holds it. A page cannot do this, and browser storage is per-device rather than shared.
Work while nobody is watching. Scheduled jobs, notifications, anything that happens when the page is closed.
If none of those apply, a page is not a compromise. It is the correct shape, and it is more robust than the alternative.
| Single page | Needs a server | |
|---|---|---|
| Calculator, tool, form | Yes | |
| Dashboard over fixed data | Yes | |
| Game, prototype | Yes | |
| Anything with a private key | Yes | |
| Two people, one changing dataset | Yes | |
| Scheduled or background work | Yes |
Browser storage is not a database
It is worth being precise because this trips people up.
Browser storage keeps values on one device, in one browser, for one person. It does not sync, it can be cleared by the user or the browser, and it is invisible to anyone else.
That makes it good for a draft, a preference, a high score, a half-finished form. It makes it wrong for anything you would be upset to lose or anything another person needs to see.
Iterate at one address
The advantage of building this way is the speed of the loop. That advantage only reaches other people if the link stays the same.
Publish at one address. Regenerate, replace what sits behind it, and tell whoever is reviewing that it is updated. They reopen the link they already have.
A new address per version throws away the loop, because now every round requires a message and half your reviewers are looking at round two.
Two checks every time you regenerate
Regeneration reintroduces problems you already fixed.
Keys. Search the file before every publish. A model that wrote a placeholder once will write one again.
Phone layout. The mobile layout is the first thing to regress, because it was something you asked for rather than something the model defaults to.
Both take a minute and both are things a reviewer will otherwise find for you.
Closely related: How to host AI generated HTML, and AI generated website and hosting for the adjacent problem.
Put it at an address
Decide whether it truly needs a server, keep it to one self-contained file if not, publish at one permanent address, and check for keys and phone layout on every regeneration.
Then the thing you built in an afternoon is something other people can actually use.