Four clicks to go live. Thirty seconds, door to done. One live server-backed app per account on the free tier. Half a second of extra latency on the very first request a brand-new subdomain ever serves, and none after that. Three of those numbers are trivia — the kind you nod at and forget by the next chapter. The "one," though, is the number that actually changes how you should work, so that's where I want to spend most of this chapter.
Why the limit is one, not zero and not unlimited
Most no-code tools that let you publish a frontend for free either don't touch server-backed apps at all, or they meter them so aggressively that "free" is a technicality. Here, a build with accounts, a database, or multiplayer state publishes through the exact same Publish button as a static page, and the server side is hosted and managed as part of that one action — no separate database provisioning, no environment variables to wire up, no discovering three days later that login works in preview and 500s in production because the backend never actually deployed. That's real, and it's why people are surprised when they hit the ceiling: everything up to that point felt unlimited.
It isn't. You get exactly one live server-backed app at a time on the free tier. Static builds don't count against it — publish as many marketing pages and portfolio sites as you want, no limit there. But the second build that needs its own database or persistent process has to wait its turn, sitting fully built and previewable, just not live at its URL. If you're prototyping three SaaS ideas in the same week, only one gets to be the one occupying real compute; the other two are finished products with no address. I think the line is drawn in a reasonable place — a static bundle costs the platform almost nothing to serve at the edge, a warm server process doesn't — but it means the decision of which idea deserves the slot has to happen before you hit Publish, not after you've already gotten attached to having two live at once.
The four clicks, for the record
- On the build's card, choose Publish.
- Pick a slug — the yourname in
yourname.buildmidas.com. Taken slugs suggest alternatives. - Confirm.
- Copy the URL off the card, or find it later on your Published page.
No DNS, no external accounts, no waiting for propagation. And about that half-second: it isn't a queue or a "check back in 24 hours" delay, it's just ordinary CDN cache warming. The first visitor to a new subdomain might catch a beat of extra latency while the nearest edge node pulls the asset bundle; the second visitor, and everyone after, gets it from cache. In practice you won't notice — you'll publish, tap the link, and it'll already feel instant. I only mention it because someone who screenshots load times for a living will eventually ask why request one and request ten aren't identical, and now you know.
The slug is the one decision worth slowing down for
Everything else in this flow is mechanical; the slug is the part a human has to say out loud or type from memory, so it's worth a beat of thought. "demo-v2-final-final" is fine for internal testing and a bad thing to text a client. Say the URL to yourself before confirming — riverside-cafe.buildmidas.com reads cleanly, riverside-cafe-mvp2.buildmidas.com doesn't. Short, generic words go fast on a platform that's been around a while, which is why a taken slug gets you suggestions instead of a bare error. Take one or reject it, but decide on purpose — I've watched people grab whatever the box offered mid-demo because they needed a link immediately, then live with an awkward name for months because there was never a natural moment to go fix it.
Republishing doesn't touch what's live until you say so
Here's a fact worth internalizing early: editing a published build doesn't move the live site. You can break things, try a wild layout change, iterate for a week — the URL a client already has bookmarked keeps serving whatever you last published, right up until you deliberately publish again.
That's your entire rollback story, and it's good precisely because it's boring. Version 6 ships a bug — a form that silently stops submitting — and you don't reach for a revert command or a support ticket. You open the version history, find version 5, republish it. Same button, older artifact, live URL flips back immediately. Then you fix version 6 with zero pressure, because production isn't broken while you work. The tax on this is one extra click per release, since you have to remember to actually publish instead of assuming an edit went out automatically. Compare that to tools where every save is live — great in a demo, rough three weeks into real use — and the extra click is a trade worth making every time.
Unpublish means the URL stops resolving, not "stops being listed"
A lot of platforms use "unpublish" to mean hide it from a gallery page while the URL quietly keeps serving. Here it means the address goes dark, full stop — no cached page, no placeholder, nothing resolves. The build itself survives with every version intact; republish later and the same slug comes back exactly where you left it. I've used this for the mundane reason (a client engagement ended, nobody wants their old logo floating at a public link) and for the less mundane one (a build leaked something it shouldn't have, and it needed to be offline in the time it takes to click a button, not the time it takes to file a ticket with a hosting provider). Both situations want the same guarantee, and both get it.
One more thing worth not conflating: publishing makes a URL live for anyone with the link; whether it's discoverable — listed publicly, sometimes surfaced in the Showcase — is a separate toggle entirely. Plenty of legitimate published sites should stay link-only forever, and a build opted into public listing is still just a normal published site underneath, with the same history and the same unpublish button.
