From prompt to URL in 90 seconds

Imagine you want a small page where your parents can see new photos you upload. Nothing complicated. You just want it online, with a link you can text them.

Two years ago that was a half-day of tutorials. Today, if you are using an assistant that can call hosting tools, it is closer to ninety seconds.

This post walks through what happens in those ninety seconds, and which parts of the old workflow you never have to touch.

What you actually say

You open Claude or Cursor or whatever assistant you use. You type something like:

Make a simple webpage where my parents can see new photos I upload. Put it online and give me a link.

You do not specify a framework. You do not pick a runtime. You do not name the project. The assistant handles all of that, because it has tools.

What the assistant does

There are about five steps, and you see none of them directly.

It writes the code. For something this small, a static site is probably the right shape, so it generates the HTML, the CSS, and a tiny upload form.

It writes a percher.toml. That is a config file telling Percher how to build and run the site. The assistant fills it in. You will not read it.

It calls percher_publish. That is an MCP tool. It uploads the files, builds them in a container, and starts the site behind a real URL.

Then it waits. Builds usually finish in 15 to 30 seconds.

Then it sends you the link.

That is the happy path. Total time, including the assistant writing the code, is about a minute and a half.

What happens when it breaks

It will break. Not always, but often enough to talk about. The assistant guesses wrong sometimes. A package version mismatches. A storage key needs to be set. The config has a typo.

This is the part of the loop where MCP-first hosting earns its keep.

When the build fails, Percher returns a structured error with a nextAction field, not a paragraph of prose. The assistant reads that field and calls percher_doctor. Doctor looks at the actual failure, classifies it, and hands back the next move.

You see one line in the chat:

Build failed because the upload form needs a storage key. Setting it now.

The assistant sets the key. It redeploys. Twenty seconds later you have a working link.

You did not see the error. You did not paste a log into anything. You did not learn what a deploy is.

What you did not have to do

If you have published a side project the old way, this list will be funnier than it should be.

• Sign up for a hosting account in a new tab.
• Pick a region.
• Open a dashboard.
• Read any documentation.
• Know what a build is, that builds happen, or that they sometimes fail.
• Copy a log out of one window and into another.
• Run a command in any terminal.

Some of this was already possible with a few tools and a lot of patience. What is new is that you can do all of it from inside one conversation, without leaving the place where you described what you wanted.

The new bar

The cost of having a thing online used to be a half-day of YouTube tutorials. The new cost is being able to describe what you want.

That sounds like a small change. It is not.

It means a lot of people who were never going to learn the old workflow can now build the thing they have been thinking about for a year and ship it before dinner. The rest of us, the ones who already knew how, just get to skip the dashboard.

Either way, the dashboard is no longer in the way.