Web Infrastructure and Landing Pages

Your website isn't marketing you get to defer to launch week. For a mobile app it's a submission dependency, two of its pages are required before a store will accept you. Build it early, and it becomes the one asset you fully control.

The concept

Almost every product needs a public web presence, and it does more jobs than founders expect:

Two of those are hard requirements for app stores. A Privacy Policy URL and a Support URL must resolve before you can submit (Chapter 36). So the website is not deferrable, it gates your launch.

The landing page

One page, one job: get the visitor to do the one thing. Structure that works across product types:

 HERO ──────── one line: who they become / what they get, + the CTA, above the fold
 PROBLEM ───── their current pain, in their words
 PRODUCT ───── what it is, with real screenshots (not mockups)
 HOW ───────── the loop or workflow, 3 steps
 PROOF ─────── testimonials, logos, numbers — real, or omit
 CTA ───────── the single action, repeated
 FOOTER ────── privacy · terms · support  ← required links

One CTA, repeated. Not "sign up" and "read the blog" and "follow us." A landing page with three goals has none. And write the copy from your customer's words (Chapters 4, 43), not your feature list.

Hosting

For a static or lightly-dynamic site, modern hosts give you global CDN, HTTPS, preview deploys and instant rollback for free. You almost never need a server for a marketing site.

Set cache headers deliberately (Chapter 17): hashed assets immutable, HTML revalidated, and, critically, no-store on any service worker, which is one of the few unrecoverable web mistakes.

Performance is conversion

A slow landing page loses the visitor before it loads. The highest-leverage fixes:

1. Optimise the hero image. It's usually 60-80% of page weight. A photographic PNG is typically 10-20× larger than a JPEG or WebP of the same image. This single fix is often the whole performance problem.
2. Set image dimensions to prevent layout shift.
3. Preload the critical font, font-display: swap.
4. Ship minimal JavaScript. A marketing page rarely needs a framework.

Optimise the pipeline, not one image. Add a pre-deploy check that fails on any image over ~300 KB, otherwise you fix the hero and ship four other 2 MB files.

SEO basics that cost nothing

• <title> and meta description per page.
• Open Graph tags, og:title, og:description, and especially og:image (absolute URL). Every share on any platform renders that card; a missing or broken og:image turns a recommendation into a grey box at the moment someone is vouching for you.
• robots.txt and sitemap.xml.
• Semantic HTML and one <h1>.

Realistic expectation: SEO for a brand-new domain in a competitive space delivers roughly zero traffic for months (Chapter 46). Do it once, correctly, then stop thinking about it. Launch traffic comes from elsewhere.

The apex/www decision

Pick one canonical host (example.com or www.example.com), redirect the other to it, and make sure the one you put on your store listing actually resolves. Test both.

📐 Best practice

Ship the site before you need to submit, its legal and support pages gate you.

One CTA, above the fold, repeated.

Real screenshots, not mockups.

Optimise the hero image, the single biggest performance win, and add a size check to the deploy.

og:image as an absolute URL, validated in a card checker before sharing.

no-store on the service worker.

Verify every required URL in incognito, apex and www, after each deploy.

Document the production branch.

A lead magnet or clear incentive on the signup form beats a bare ask (Chapter 44).

Install analytics before driving traffic (Chapter 38).

💀 Common mistakes

Deferring the site to launch week, then discovering it blocks submission.

Required URLs 404 because the wrong branch deployed.

Apex/www mismatch, you list one, only the other resolves.

PNG for photographs. 10-20× the bytes.

One image optimised, the rest shipped huge.

Broken og:image. Every share is a grey box.

Caching the service worker. Users permanently stuck on an old version.

Multiple competing CTAs. No focus, no conversion.

Mockups instead of real screenshots. Reads as vaporware; can be store-rejected.

Placeholder copy shipped live, support@example.com, lorem ipsum.

No analytics, you drive traffic and learn nothing.

The professional workflow

 1. BUY THE DOMAIN, configure DNS (Chapter 35)

 2. BUILD THE PAGES
    landing · privacy · terms · support (+ any safety/disclaimer page)

 3. ONE CTA, real screenshots, customer-language copy

 4. OPTIMISE
    hero image · dimensions · fonts · minimal JS ·
    size check in the deploy

 5. SEO
    title · description · og:image (absolute) · robots · sitemap · one h1

 6. CACHE HEADERS — hashed immutable · HTML revalidate · sw.js no-store

 7. DEPLOY to a managed host with previews + rollback

 8. VERIFY every required URL in incognito, apex AND www

 9. INSTALL ANALYTICS before any traffic

Tools, websites & costs

A complete marketing site is ~$12/year (the domain). Everything else is free.

Alternatives & trade-offs

Static HTML vs framework vs no-code. Static HTML is fastest, cheapest, and most portable, and requires you to write it. A framework (Astro, Next static) adds a build step and components. No-code (Carrd, Framer) is fastest to a polished result and adds a vendor and a monthly cost. For a landing page, any is fine; legal pages should live on your own domain regardless.

Marketing site coupled to app vs separate. A separate marketing site is simpler to iterate and can't break the app. A coupled one shares components and design. Separate is the common, safer choice early.

Self-hosted analytics vs hosted. Self-hosted (Umami, PostHog) avoids a cookie banner and a vendor; hosted is zero-setup. Privacy-first hosted (Plausible) is a good middle.

Custom design vs template. A template gets you 80% for near-zero effort; custom carries your identity. For a first landing page, a good template beats a mediocre custom build.

Checklist

• Domain and DNS configured
• Privacy, terms, support pages live, matching real behaviour
• Any safety/disclaimer page your domain warrants
• All required links in the footer
• Every URL verified 200 in incognito, apex and www
• Production branch documented
• One CTA, above the fold, real screenshots
• Hero image under ~150 KB; size check in the deploy
• title, description, absolute og:image (validated), robots, sitemap, one h1
• sw.js served no-store
• No placeholder copy (grep for example.com, lorem, TODO)
• Analytics installed before any traffic

📓 Case Study: the deploy that 404'd the required URL

Project: SOLIS. The website work began not as marketing but as a launch-checklist item, the store required a Privacy Policy URL and a Support URL, and the app couldn't be submitted without them.

Three pages were built, each with a specific job: a privacy policy, a support page (contact + FAQ, the store's Support URL), and a wellbeing/disclaimer page, the last one voluntary, existing purely to demonstrate responsibility to a reviewer for a product that touched low mood.

💀 The deploy that 404'd the required URL. The site went live via a managed host connected to the repo, and immediately:

"ok its live now, but where is the support and other pages? that is required by appstore"

The pages existed, on the integration branch. The host deployed the production branch. So the site was live and its two mandatory store URLs returned 404. Fixed by merging the branches.

📐 Write down which branch is production, and verify every required URL in incognito after each deploy. Every "why isn't my change live" incident in software is a version of this, and here it was a submission blocker.

Post-fix verification was done properly: all pages verified 200, home, privacy, support, disclaimer, and the hero asset, with the site canonicalizing correctly (apex redirecting to www, apex URLs still resolving). Checking the apex/www redirect specifically matters: if you list example.com/privacy and only www. resolves, your mandatory URL is broken.

The hero image: 1.9 MB → 117 KB. A single commit: "optimize website hero (1.9MB PNG → 117KB JPEG)." 16× smaller, visually identical. A photographic image had shipped as a lossless PNG.

⚠️ But the fix stopped at one file. The same asset folder still held a 1.9 MB logo, two ~1.8 MB scene images, and a 1.5 MB avatar.

📐 Optimising one image is a fix; optimising the pipeline is a solution. A pre-deploy check failing on anything over ~300 KB would have caught all of them.

SEO was done cheaply and correctly. Prompted by "is the website SEO optimized?", everything that matters went into the <head>, title, description, canonical, a full Open Graph card with an absolute og:image and descriptive alt text, robots.txt, and sitemap.xml. The highest-ROI item there is the og:image: every share on any platform renders that card, and it costs one meta tag.

A lead magnet raised signup conversion. Rather than a bare "join the waitlist," the page offered a free PDF for signing up, turning an ask into an exchange, and demonstrating quality before the product existed (Chapter 44).

⚠️ Deviation: the site had no analytics. The waitlist conversion rate, traffic sources, and bounce rate were all unknown, because nothing measured them. Driving traffic to an uninstrumented page means learning nothing from it (Chapter 38).

Lessons

1. The website is a submission dependency, not marketing. Two pages are mandatory.
2. Name your production branch and verify after every deploy. The 404 was a branch mismatch, and a store blocker.
3. Test apex and www. Your store listing uses one exact string.
4. Optimise the hero image, the biggest single performance win, and check the whole pipeline.
5. og:image is the highest-ROI meta tag. Every share depends on it.
6. Never cache the service worker.
7. One CTA, repeated. Real screenshots.
8. A lead magnet converts better than an ask.
9. No placeholder copy in production.
10. Install analytics before you drive traffic. Retroactive data doesn't exist.

Next: Chapter 35: Domains, Email and Deliverability →