An AI tool builds the landing in fifteen minutes; deciding where it lives takes the next hour. Three hosting shapes and how to pick between them.
The product idea showed up Wednesday afternoon. By Thursday morning the landing page exists — copy, sections, illustrations, a call-to-action button. The AI tool produced the whole thing in a single multi-turn session.
The page is at a URL that ends in .v0.app or .lovable.app or some other tool-specific subdomain. Sending the link to a couple of friends works; putting it in a launch post next month is a different framing question.
Where the landing should live depends on what the next few months look like.
Every AI builder ships with a one-click hosting path that produces a URL on the tool's domain. v0 publishes to https://<something>.v0.app. Lovable publishes to https://<something>.lovable.app. Bolt has a similar workflow with bolt.host or StackBlitz subdomains. The deploy is instant; the URL is shareable; the cost is zero.
What this is for: the first week. Pre-validation, friend feedback, "does this work as a one-page pitch" check. The tool's branding on the URL reads as built with this tool which is correct framing while the project is genuinely in that mode.
Where it stops fitting: when the product gains its own positioning. A URL ending in another company's domain reads differently to a hesitant prospect than a URL at the product's own domain. The trust signal is small and consistent.
Exporting from the AI tool and deploying to Vercel, Netlify, Cloudflare Pages, or Render gives the landing the full shape of a deployed project: custom domain, environment variables, deploy previews per git branch, edge functions if needed, analytics dashboards, CDN caching.
This is the right shape when:
It's overhead when:
For a one-person indie product, the deploy pipeline is real work that competes with the actual product work.
The third shape: export the AI tool's output as a single self-contained HTML file (most builders support this; the cross-tool prompt patterns for portable HTML cover what to ask for so the export comes out clean), then host that file at a private-link service with optional searchable opt-in.
The trade-off:
For a landing that's essentially static for the first few months of a product launch, this shape covers the gap between "tool subdomain" and "full Vercel deploy" without committing to the maintenance overhead of the latter.
Three sets of questions, in order:
Is this landing going to evolve into a full web app?
Does the landing need its own custom domain (yourproduct.com)?
How often will the landing update?
Most indie product launches answer "no, yes, weekly-ish" in the first six months — which puts them in the static-host middle ground until the product grows into needing a real deploy pipeline.
Studio plan ($14.99/mo) hosts the landing at your product's own custom domain, removes the footer, and lifts searchable opt-in to unlimited — so the landing page can be indexed by Google and AI answer engines while everything else on the account stays private by default.
A private-link host that defaults to noindex (which is the right shape for most private-delivery use cases) needs an explicit toggle for public landings — otherwise the landing page is invisible to Google, which defeats most of the point of a landing page.
The shape to look for in pricing pages: per-document searchable opt-in. A single landing page becomes indexable; the rest of the account stays default-private. On miinideck the opt-in starts on the free tier — one searchable page — and scales up to five on Solo and unlimited on Studio; the higher tiers add headroom and, on Studio, the custom domain that makes the landing read as your product's own.
For an indie product where the landing is the only public surface, this configuration — Studio plan + custom domain + searchable opt-in on that one page — is roughly the same operational shape as a small Vercel project, with the upside of no build pipeline and no deploy command.
Most AI builders ship a "Export" or "Download" path that produces either a multi-file project (good for cloud deploy) or a single HTML (good for static host):
For the static-host path, the file is what you upload. For the cloud-deploy path, the project archive goes to GitHub and the deploy is automatic from the branch.
The static-host path doesn't replace a full deploy platform for a real web app. Once the product has signup, payments, user accounts, dynamic content, A/B tests, or any backend logic — it's a project, not a landing. The right shape is Vercel / Netlify / Cloudflare Pages with a proper deploy pipeline.
The boundary is roughly: if the landing is "screenshots + copy + a CTA to a Stripe link", static-host fits. If it's "signup form + dashboard preview + interactive demo", deploy platform fits. Most landings start in the first shape and graduate to the second over months, not weeks.
For products still in the first shape, the static-host path is the lightest workflow that supports a real custom domain. For products already past it, the migration to a cloud deploy platform is small and the right move.
It looked like a URL. You sent it. It doesn't exist — and never did. Why models produce link-shaped text when you ask them to share something, how to spot it in one second, and what actually has to happen for a real link to exist.
The agent handed you a URL and said it's live. It probably is. What it didn't tell you is who can open it, how long it lasts, whether the address is guessable, and what happens to it when you revise — four defaults chosen for you, none of them announced.
ChatGPT Sites hosts what you build and gives you access controls — owner only, named workspace members, the whole workspace, or the public internet. There's no rung for one outside client. Here's the shape of that gap and the route round it.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.