Use-case landing pages for agencies, freelancers, and SaaS

[ezzcodeezzlife]

Summary

The homepage is one generic story (“feedback automation for agencies and freelancers”). We should add separate landing URLs per use case, each with its own headline, proof, FAQ, and SEO, all still signing into the same app.

Today the only public indexed routes are / and /legal (app/sitemap.ts). Use cases live as a section on the home page (#use-cases in components/home/landing-view.tsx), not as pages.

Current marketing surface

• / — SITE_PAGE_TITLE = “Feedback Automation That Opens GitHub PRs” (lib/site-config.ts)
• Keywords: generic “feedback widget”, “AI feedback agent”, etc. (app/page.tsx)
• JSON-LD: WebSite, Organization, SoftwareApplication, HowTo, FAQ (components/seo/home-next-seo.tsx)
• Home FAQ already includes “Can I customize the widget appearance?” → “coming soon”
• Use-case cards (home only):
  1. Digital Agencies & Studios
  2. Freelance Developers
  3. Retainers & Maintenance
  4. Client Handoffs
• README also mentions SaaS, docs, internal tools as secondary fits
• Navbar: #pricing only (components/navbar-landing-links.tsx)
• Logged-in users never see the landing (app/page.tsx redirects to /dashboard)

Why separate pages

One URL cannot rank for “agency client feedback widget”, “freelance website change requests”, and “SaaS in-app feedback to GitHub” at once. More importantly, conversion copy differs:

Audience	Job to be done	Fear	CTA emphasis
Agency	Stop Slack screenshots from five clients	Client sees a botch on production	“Nothing ships until you merge” + multi-repo
Freelancer	Batch change requests, bill the time	Scope creep / unpaid tweaks	PR as the unit of work
Retainer	Make maintenance boring and recurring	Widget on the live marketing site looking ugly	Theme + path allowlist
In-house / SaaS	Route user reports into the real codebase	Public widget spam / noise	Turnstile, domains, path allowlist
Client handoff	Non-technical client can request changes	They will “break the site”	Review gate, no prod push

Same product; different first screen.

Proposed IA

Keep / as the primary brand/SEO page (do not starve it). Add:

Path	Audience	Canonical
/for/agencies	Studios with a client roster	self
/for/freelancers	Solo / small	self
/for/retainers	Maintenance retainers (can merge with agencies if thin)	self or redirect → agencies
/for/saas	In-house product / docs	self

Start with three: agencies, freelancers, saas. “Retainers” and “handoffs” can be H2s on the agency page unless they have distinct search demand.

Shared layout: same navbar, same pricing snippet, same GitHub signIn. Unique: hero, 3 bullets, 1 walkthrough, 4 FAQs, OG title/description.

Implementation approach (assumption)

Do not fork landing-view.tsx four times (it is already ~1.3k lines). Extract:

• LandingShell (nav, footer, pricing, stack, pipeline viz — mostly shared)
• UseCaseHero driven by a typed config module lib/marketing/use-cases.ts

Each app/for/[slug]/page.tsx (or explicit routes) exports metadata + JSON-LD for that page. Add to app/sitemap.ts. Add <link rel="alternate"> only if we later translate; not needed for v1.

Internal links: home use-case cards become real <Link href="/for/agencies"> instead of dead cards.

OG images: reuse /opengraph-image in v1; per-page OG is a follow-up if these pages get traffic.

Assumptions

• We are not building separate products or feature flags per persona. After OAuth everyone hits the same dashboard.
• Intent survey (separate issue) uses the same enums (agency, freelance, in_house) so we can later say “people from /for/agencies actually checked agency.”
• No locale-specific landing pages in this issue (EUR/USD is billing, not /de).
• Do not add a blog/CMS. Static TSX is enough.
• robots.ts already allow: /; new pages inherit that. Confirm they are not under a noindex layout.

SEO details to actually do

• Unique <title> and meta description per page (~155 chars), lead with the query (same discipline as SITE_PAGE_TITLE).
• Canonical self-URL via alternates.canonical.
• FAQ JSON-LD per page (do not copy the home FAQ verbatim; 2–3 overlapping answers is fine).
• H1 once, matching the title intent.
• Sitemap priority 0.8 for /for/*, 1.0 for /.
• Avoid keyword-stuffing the same paragraph on all three pages (thin-content risk).

Example titles (draft, not final copy):

• Agencies: “Client Website Tweaks as GitHub PRs”
• Freelancers: “Turn Client Change Requests into Pull Requests”
• SaaS: “User Feedback That Opens a PR in Your Repo”

Acceptance criteria

• /for/agencies, /for/freelancers, /for/saas render unique heroes and FAQs, share pricing + sign-in.
• Each has unique metadata, canonical, and sitemap entry.
• Home #use-cases cards link to these pages.
• Logged-in users hitting /for/* still see marketing (do not redirect to dashboard — these are shareable sales URLs). Only / redirects when logged in, as today.
• Lighthouse/SEO: no duplicate H1, pages are indexable.
• No large additional JS bundle: config-driven, not four copies of the pipeline animation.

Out of scope

• Paid ads / UTM landing variants (/for/agencies?utm=… can wait).
• Customer logos / case studies (we likely do not have them yet).
• Localization.

Implementation notes

• Refactor components/home/landing-view.tsx carefully; it is the conversion surface.
• app/sitemap.ts currently hardcodes two URLs — extend the list.
• components/navbar-landing-links.tsx — optional “Use cases” dropdown; do not clutter. Home cards + footer links are enough for v1.

See also

• Onboarding intent survey (enums should match slugs)
• Widget theme + path allowlist (agency/retainer pages should preview those as “why agencies pick us”, even as coming soon)

[ezzcodeezzlife]

Related: onboarding survey #2 (persona enums), widget theme #8, path allowlist #5