Skip to content
ZajLibrary
prod e051e98
Browse

7 · Post-launch identity & changelog

TL;DR

Section titled “TL;DR”

Objective — handle the two post-launch tasks — claim social-media handles early (even before you post) and wire the dual changelog (internal + public) — so the brand is protected and every stable release ships with a repeatable announcement.

Background

Section titled “Background”

These two tasks run after launch — but configure the scaffolding now so you’re not scrambling on release day. Claim handles before a squatter does, and set up the changelog pipeline once so every future release is a 20-minute task.

flowchart LR
  A["1. Claim handles<br/>(once, early)"] --> B["2. Document<br/>+ wire .env"]
  C["3. Dual changelog<br/>(per release)"] --> D["4. GitHub Release<br/>+ announce"]

Steps

Section titled “Steps”

1. Claim the social-media identity (post-launch, do early)

Section titled “1. Claim the social-media identity (post-launch, do early)”

Claim handles early even if you’re not actively posting — consistent naming protects the brand. Budget ~45–60 min the first time.

  1. Define the target handle — keep it under 15 characters; prepare fallbacks like @<App>App or @<App>HQ.

    • ✅ A target handle + fallbacks are chosen.

  2. Check availability across all platforms at namechk.com before committing to one.

    • ✅ Availability is confirmed before claiming.

  3. Prepare brand assets from the brand kit — logo at 400px / 320px / 196px / 32px, per-platform banners, and a 160-character bio.

    • ✅ Per-platform logos, banners, and a bio are ready.

  4. Create the accounts you’ll actually use.

    PlatformNotes
    Twitter / XPrimary handle; pin a launch post later
    Facebook PageBusiness page, not personal profile
    LinkedIn Company PageNeeded for B2B credibility
    InstagramSwitch to a Business account
    YouTubeOptional — only if you’ll publish video
    GitHub OrgOptional — for open-source presence
    • ✅ The accounts you’ll use are created with on-brand avatar/banner/bio.

  5. Document the company info — legal name, contact emails (support@, hello@, noreply@), and important links.

    • ✅ Legal name, contact emails, and links are documented.

  6. Update ProjectCard.md with every social URL and contact address so the project’s source of truth stays current.

    • ✅ ProjectCard.md carries every social URL and contact address.

  7. Wire .env so the app’s footer/meta render the real links.

    Terminal window
    CONTACT_EMAIL=hello@<domain>
    SUPPORT_EMAIL=support@<domain>
    SOCIAL_TWITTER=https://twitter.com/<handle>
    SOCIAL_FACEBOOK=https://facebook.com/<page>
    SOCIAL_LINKEDIN=https://linkedin.com/company/<slug>
    SOCIAL_INSTAGRAM=https://instagram.com/<handle>
    # Expected: the footer/meta render the live links after a config clear
    • ✅ Every claimed handle resolves, the bio/avatar/banner are on-brand, and the footer renders the live links after a config clear.

2. Wire the changelog (post-launch, per release)

Section titled “2. Wire the changelog (post-launch, per release)”

A per-release task (~20–30 min) executed after each stable production deployment. Run a dual changelog: a detailed internal log for the team and a friendly public log for users.

  1. Set the file locations for the dual changelog.

    FilePurposeAudience
    CHANGELOG.md (root)Internal developer changelogTeam
    resources/markdown/changelog.mdPublic user changelogUsers
    ProductLift / Beamer / Canny / custom /changelogIn-app “What’s New”Users (live)
    • ✅ Both changelog files and the in-app surface are identified.

  2. Verify the documentation — git log <last-tag>..HEAD --oneline and cross-check that both the internal CHANGELOG.md (root) and the public resources/markdown/changelog.md are current.

    Terminal window
    git log <last-tag>..HEAD --oneline
    # Expected: the commits since the last tag, to cross-check against both changelogs
    • ✅ Both changelogs are current for the commits since the last tag.

  3. Publish the public changelog — pick a tool (ProductLift, Beamer, Canny, AnnounceKit, or a custom /changelog route), write a user-friendly entry (benefit-first, not commit messages), and add screenshots or GIFs.

    • ✅ A benefit-first public entry is published with visuals.

  4. Update the user + API documentation — new feature guides, refreshed screenshots, version badges; and (if you expose public APIs) new endpoints and any deprecation notices.

    • ✅ User docs (and API docs if applicable) reflect the release.

  5. Create the GitHub Release.

    Terminal window
    gh release create vX.X.X --title "vX.X.X — <Title>" --notes-file CHANGELOG.md
    # Expected: a GitHub Release is created for the tag using the CHANGELOG authored in step 1
    • ✅ A GitHub Release exists for the tag.

  6. Update the roadmap and send announcements — mark shipped features and refresh “What’s Coming”; send email (major releases only), social media, and team channels; update the status page (if you run one); send internal notifications (team channel post + a short support-team brief).

    • ✅ The roadmap is updated and announcements (public + internal) are sent.

The public changelog should show the new entry, and the in-app “What’s New” surface should reflect it.

Checklist

Section titled “Checklist”

Do not mark this step done until every box below is checked.

  • 👤 Target handle chosen — availability checked, fallbacks noted.
  • 🔀 Accounts created — on-brand avatar/banner/bio; ProjectCard.md + .env updated.
  • 🔀 Dual changelog files exist — and are current for the latest tag.
  • 👤 Per-release flow documented — so each future release is repeatable.
  • 🔀 GitHub Release + public “What’s New” wired.

Phase 9 — Growth & Polish