The part that got dramatically cheaper is producing something that works. The part that did not is everything between that and somebody else using it.
Where projects actually stop
Not at the code. At the folder.
Something works on a machine, the interesting problem is solved, and the remaining tasks are checking for exposed keys, fixing paths, testing on a phone and uploading. None of that is enjoyable and none of it was prompted for.
So the folder stays, the momentum goes, and a week later it is one of several folders nobody opens. This is the normal outcome and it has nothing to do with the quality of what was built.
The four checks
Keys. Anything in a page is public. Generated code puts credentials directly into files regularly, because it is completing a pattern rather than weighing exposure. Search before publishing.
Paths. A path beginning with a slash points at the root of wherever it lands. Right locally, wrong once published, and the page arrives with no styling.
Phone width. Narrow the browser window until it is phone-shaped. If the layout does not reflow, half your visitors get an unusable page, and you will hear about it from them rather than from testing.
Server or not. If nothing has to run when a visitor arrives, publishing is uploading a folder. If something does, that is a different arrangement and it is better to know before building than after.
| Check | Takes | Catches |
|---|---|---|
| Search for keys | 1 minute | Exposed credentials |
| Fix absolute paths | 2 minutes | The unstyled page |
| Narrow the window | 1 minute | Unusable on phones |
| Server question | 2 minutes | The wrong publishing route |
| Open the live address | 1 minute | Everything else |
Publish the smallest version
The single useful thing, with no accounts, no saving, no settings.
That version can be published today. It will be used today, which tells you more in an afternoon than another week of building would.
Everything afterwards is an addition to something real, rather than another reason the thing is not ready.
Send an address, not a file
A file asks somebody to download it, find it and open it, and on a phone that is three steps too many.
An address is one tap. The page opens, the thing works, and they tell you what is wrong with it.
That difference decides whether anything you built gets looked at, and it applies equally to a tool, a report and a brochure.
Two neighbouring cases are worth a look: Hosting what you built by prompting and How to host AI generated HTML.
Put it at an address
Decide the address before building, search the source for keys, narrow the window to phone width, publish the smallest useful version, and send the address rather than the file.