Does your app need a website?
Somewhere on every launch checklist, between the icon and the release notes, sits "build the website" — a line item that feels mandatory and expands to fill whatever week you give it. Most of it can wait. What can't wait is much smaller than a website: a domain, three static pages, and two files you'll be glad you hosted. The useful question isn't whether to build a site — it's which parts your app actually needs, and when.
The stores set the minimum, not you
Before your app can even reach review, both stores demand URLs. Apple requires a support URL and a privacy policy URL for every app in App Store Connect; Google Play requires a privacy policy link for every app in Play Console. These have to be live, publicly reachable web pages — a dead or placeholder link is the kind of thing that surfaces during review, and it's an embarrassing way to lose a launch day.
So the floor is fixed: a domain and a couple of static pages, before submission. The good news is how cheap the floor is. A domain runs $10–15 a year, static hosting is free on the hobby tiers of Cloudflare Pages, GitHub Pages, or Netlify, and a privacy policy plus a support page is an evening of writing, not a project. That's the entire mandatory budget. Everything past it is optional — which is exactly why it deserves scrutiny.
Four jobs only a domain can do
The domain matters more than the site on top of it, because several things you'll want later are impossible without one — and painful to retrofit.
1. Deep links that survive. Universal Links on iOS work by serving an
apple-app-site-association file from your domain over HTTPS; Android App
Links work the same way with a /.well-known/assetlinks.json file carrying
your signing key's SHA-256 fingerprint. Without a domain you're left with custom URL
schemes, which any other app can also claim and which both platforms now treat as
second-class. If you ever want a shared link, a password reset, or an invite to open
your app instead of a browser tab, the domain is the prerequisite.
2. An email address that isn't a Gmail. Google Play displays your support email
publicly on the listing. [email protected] reads like a product;
a personal Gmail with digits in it reads like a weekend experiment. The same address
later becomes the sender for receipts and account emails, and moving providers is far
easier when the address is on a domain you control.
3. One link that routes. A podcast mention, an app-review video description, a
social bio, a QR code on a poster — each gives you exactly one link slot, and you can't
paste two store URLs into it. yourapp.com/get that redirects by device
solves this permanently, and it keeps working when you add the second platform, change
store URLs, or run a promotion.
4. Being findable outside the stores. When someone hears your app's name and
searches the web instead of the store, you want to own that result — not a
keyword-squatting "review" site running ads against your name. And once the page
exists, one meta tag (apple-itunes-app) makes Safari show a Smart App
Banner that turns any visit into an install path.
The job a website will not do
The fantasy version goes: publish a beautiful site, visitors find it, installs follow. For a new indie app that funnel barely exists. Nobody is searching for a product they haven't heard of, and content that earns search traffic takes months of compounding before it pays anything at all. Meanwhile every install decision — every single one — happens on your store product page. People who tap your link spend a few seconds on your homepage confirming you're real, then head to the store, where your screenshots and description either close the install or lose it.
That ordering has a practical consequence: a launch week spent polishing a scroll-animated homepage while the store listing runs raw UI dumps is effort invested at the wrong end of the funnel. The homepage needs to establish legitimacy — icon, one sentence, one screenshot, a store button per platform. One screen. The listing is where the actual selling happens, and it deserves the design time first.
When a real site earns its keep
None of this means websites are a trap — it means a website should be hired for a job. Four jobs genuinely justify one. A pre-launch waitlist, because an email list is the only launch channel you own outright. Content, if you'll commit to answering questions your future users actually search — a long, compounding game that starts paying quarters in, not weeks. Web checkout, because selling subscriptions on your own site, where the rules allow it, keeps the store commission — it's why so many apps price their web plan below the in-app one. And a web version of the product itself, at which point the site isn't marketing anymore; it's the app.
If none of those four apply to you yet, the one-screen version is not a compromise. It's the correct size.
The one-evening build
The whole mandatory tier fits in a single evening. Register the domain. Point it at a
free static host. Ship four pages: a one-screen home (icon, one line, one screenshot,
store buttons), /privacy, /support with a real email address,
and /terms if your app has accounts or purchases. Drop the two
/.well-known files in when you're ready for deep links, add the Smart App
Banner tag, and stop. Total cost: the domain. You will spend more time choosing the
template than building the site — which is fine, because the site is not where your
installs come from.
Polish the page people actually land on
However good the homepage gets, the install decision happens on the store listing — and that's the page ShotCanvas is built for. Drop in your raw screens, pick a template or let AI compose the set and write the headlines, and export pixel-exact screenshots for every App Store and Google Play slot — or publish straight to both stores. The free tier covers your first sets, no credit card.