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.
You sent a Claude Slides deck with 'anyone with the link' and your client got a sign-up screen. Why that happens, what Docs, Slides and Design actually export, and how to get the work in front of someone who will never make a Claude account.
You sent a client the public link to a Claude Code artifact and asked them to mark up what to change. There's nowhere to comment. That's by design. Here's the rule, which plans it leaves without a comment option for outside viewers, and how to collect pinned notes anyway. Checked against Anthropic's docs on 15 September 2026.
Hit a ChatGPT Sites usage limit? Your Sites aren't gone. Here's how to tell the ones that are just pages, which travel, from the ones that need Sites underneath them.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.