heremyapp/docs llms.txt
View as Markdown

Landing page checklist

heremyapp exists so people can put their app or web service online quickly, without setup chores or things they need to know in advance. A good landing page is part of that.

Agents: use the whole checklist when you create or redesign a landing page, and fill in what the user would otherwise miss. For a routine release, update only the release information (version, size, date, release notes, structured data) and fix anything clearly broken; do not add languages or sections unless the user asks.

Contact and business details (ask once)

curl -sS --fail-with-body "$API/spaces/my-app/contact" -H "$AUTH"    # {"status":"unknown" | "provided" | "skipped", ...}
  • unknown: ask the user once, in their language, and say that skipping is fine. For example: "Do you want contact details on the page? Tell me any of: email, business name, support phone, address. You can also skip this." If another of the account's spaces already has contact details (GET /spaces/OTHER/contact), offer to reuse them. When you are creating a page, ask about languages in the same message (see below), so the user answers once.
  • Save the answer so nobody asks again. Each PUT replaces all saved details and sets status to provided (or skipped), so send every field you want to keep:
curl -sS --fail-with-body -X PUT "$API/spaces/my-app/contact" -H "$AUTH" -H "content-type: application/json" \
  -d '{"business_name":"Acme Inc.","contact_email":"support@acme.example","phone":"+82-2-123-4567","country":"KR"}'
curl -sS --fail-with-body -X PUT "$API/spaces/my-app/contact" -H "$AUTH" -H "content-type: application/json" \
  -d '{"status":"skipped"}'
  • provided or skipped: do not ask again unless the user brings it up.
  • Fields: business_name, representative, contact_email, phone, support_url, address, country (two letters, e.g. KR), registration_number.
  • Show them in a footer or a "Contact" section. Use a mailto: link for email.
  • Some countries require business details on sites that sell to consumers (for example South Korea's e-commerce law asks sellers to show business name, representative, registration number, address and contact; Germany requires an Impressum). If country suggests this, mention it to the user. Do not present it as legal advice.

What the page should contain

  • App name, icon and a one-sentence value proposition at the top
  • What it does: three to six key features, screenshots with alt text, optionally a short video (mp4 or webm)
  • A download button pointing at the absolute latest_url, with version, file size, release date and requirements (minimum OS, Apple silicon or Intel)
  • Install steps and first-launch notes; how to uninstall
  • Release notes from the installer's notes
  • SHA-256 checksum for people who verify downloads
  • Contact or support, and pricing if any
  • A privacy policy at /privacy and terms of use at /terms, linked from the footer (or header) of every page (Privacy policy and terms)

Often missed

  • <title> and <meta name="description">, written for each language
  • Link previews: og:title, og:description, og:image (1200×630, absolute URL), og:url (the public URL) and twitter:card, so shared links look right in Slack, KakaoTalk, X and messengers
  • favicon.ico or an SVG favicon, and a 180×180 apple-touch-icon.png
  • Structured data: a JSON-LD SoftwareApplication block (name, operatingSystem, applicationCategory, softwareVersion, downloadUrl, offers with the price) for search engines and AI assistants
  • An llms.txt at the site root that describes the product in plain Markdown for AI assistants
  • A 404.html, a layout that works on phones, readable contrast, and the page itself following the system dark mode
  • No secrets, tokens or private keys in any file

Multiple languages

Make the page easy to share worldwide:

  • When creating a page, publish in English and in the user's own language unless they say otherwise. Offer more languages (for example Japanese, Simplified Chinese, Spanish) in the same question as the contact details. If the user skips or has no preference, use the default and go on.
  • Later releases keep the languages the site already has, and update every language version.
  • Write installer notes in English; translate them on each language version of the page.
  • Put the default language at / and the others in folders named with language codes: /ko/, /ja/, /zh-Hans/.
  • Set <html lang="..."> on every page, add a visible language switcher with plain links (never redirect by location), and add hreflang alternates with absolute URLs based on the space's site_url, including x-default.
  • Translate everything visible, including the title, description and link-preview text. Keep the same download link.
  • Adding a language is a minor release.