Ghost: the product plan

A product plan on ProductBrain: 6 goals, 25 needs, 42 approaches, 45 jobs. Goals hold the why, needs the user problems, approaches the bets, jobs the checkpoints. This is a live, read-only ProductBrain plan; the interactive tree and matrix load when scripts run.

how this plan was built (the full agent transcript) · all public plans · ProductBrain

Goal: Ghost is fast, open infrastructure teams can self-host and trust

A headless, open-source Node.js CMS that runs anywhere, exposes stable versioned APIs, localizes globally, and stays secure and reliable at scale.

  • need: Integrate with any stack through clean APIs

    Headless Content and Admin APIs plus events for automation.

    • approach: Content & Admin REST APIs (resolved)
    • approach: Webhooks & integrations (resolved)
  • need: Run anywhere and stay effortlessly up to date

    Self-host with simple install/upgrade and swappable infrastructure.

    • approach: Self-hosting via Ghost-CLI and Docker (resolved)
    • approach: Pluggable infrastructure adapters (storage, SSO, scheduling, cache, redirects) (validation)
  • need: Serve a global, multilingual audience

    Localize the whole platform across many languages.

    • approach: Full-platform internationalization (60+ locales) (validation)
  • need: Stay secure and trustworthy

    Protect accounts, moderate abuse and handle vulnerabilities responsibly.

    • approach: Authentication and staff 2FA (resolved)
    • approach: Comment moderation and spam defense (validation)
    • approach: Coordinated vulnerability disclosure and patching (resolved)
  • need: Control routing and URLs as sites evolve

    Manage redirects and dynamic routing without breaking links.

    • approach: Custom redirects and dynamic routing (YAML) (validation)

Goal: Ghost stays fast to build on

A modern, maintainable codebase — React admin, Lexical editor, a shared design system, TypeScript, and end-to-end tests — so the core team and open-source contributors ship quality faster.

  • need: The admin is one fast, modern app

    A unified React admin replacing the legacy Ember client.

    • approach: Migrate Ghost Admin from Ember to React (development)
      • job: Consolidated React admin shell with client-side routing (done, phase: Admin on React)
      • job: Members management runs in React (done, phase: Admin on React)
      • job: Posts list and editing surface in React (done, phase: Admin on React)
      • job: Analytics dashboard runs in React (done, phase: Admin on React)
      • job: Settings composed from admin-x-settings in React (done, phase: Admin on React)
      • job: Tags management runs in React (done, phase: Admin on React)
      • job: Standalone React admin boots without the Ember shell (done, phase: Admin on React)
      • job: New admin UI is built on the Shade design system (done, phase: Admin on React)
      • job: Remaining Ember admin screens migrated to React (phase: Admin on React)
      • job: Retire admin-x-design-system in favor of Shade (phase: Admin on React)
  • need: The codebase stays typed, tested and maintainable

    TypeScript, ESM and end-to-end tests keep velocity high as Ghost grows.

    • approach: TypeScript & ESM modernization of the backend (development)
      • job: Admin API schemas converted to TypeScript (done, phase: Typed platform foundation)
      • job: Ping services (Slack, Explore, IndexNow) rebuilt as typed service classes (done, phase: Typed platform foundation)
      • job: Adapters load via package exports and ESM (done, phase: Typed platform foundation)
      • job: Admin API schema packaged inside the Ghost workspace (done, phase: Typed platform foundation)
      • job: Server services incrementally migrated from JavaScript to TypeScript (phase: Typed platform foundation)
    • approach: End-to-end and unit test coverage (Playwright + Vitest) (validation)

Goal: Creators publish professional content without fighting their tools

The core writing, design, and content-management experience: a fast, beautiful editing surface and clean library management so independent publishers produce polished work without technical friction.

  • need: Writing feels effortless and never loses work

    A distraction-free, fast composition experience where drafts are always safe.

    • approach: Koenig editor built on Lexical (development)
      • job: Link suggestions offer internal share links inside the editor (done, phase: Editor productivity)
      • job: Default card library renders identically in editor and published post (done, phase: Editor productivity)
      • job: Lexical and HTML renderers keep published output stable (done, phase: Editor productivity)
      • job: Real-time collaborative editing (phase: Editor productivity)
      • job: Large-document editing stays smooth (typing latency) (phase: Editor productivity)
    • approach: Autosave and post revision history (resolved)
  • need: Rich media and layout without hiring a designer

    Embed media, cards and interactive blocks that look designed out of the box.

    • approach: Dynamic card library (bookmark, gallery, embed, callout, product, …) (resolved)
    • approach: Media and file handling with responsive images (resolved)
  • need: Manage a growing library of posts, pages and tags with confidence

    Organize, find, bulk-edit and schedule content as the archive scales.

    • approach: Posts, pages and tags management (resolved)
    • approach: Scheduled publishing (resolved)
  • need: The published site looks on-brand and professional

    Themes and brand controls make the public site polished without touching code.

    • approach: Handlebars theme engine and marketplace (resolved)
    • approach: Custom theme settings and brand controls (resolved)
  • need: Content is discoverable and syndicated

    Readers and machines find the content: search, SEO and syndication signals.

    • approach: SEO essentials (meta, canonical, sitemaps, structured data) (resolved)
    • approach: On-site search (sodo-search) (resolved)
    • approach: Syndication signals (IndexNow, webmentions) (validation)

Goal: Publishers grow an audience they own — not rent

Convert anonymous readers into known members and subscribers and reach them directly via email and the open social web, so the audience relationship belongs to the publisher, not a third-party platform.

  • need: Turn anonymous readers into known members

    Frictionless, passwordless signup that captures the reader relationship.

    • approach: Portal membership widget (passwordless signup & account) (resolved)
    • approach: Embeddable signup forms (resolved)
  • need: Reach the audience directly by email

    Own the inbox: publish newsletters straight to subscribers at any scale.

    • approach: Newsletters with scalable bulk email (resolved)
    • approach: Multiple newsletters with per-member preferences (resolved)
  • need: Understand and organize who members are

    Capture and segment member attributes to personalize and target.

    • approach: Member custom fields (development)
      • job: Custom field definitions and permissions live in the database schema (done, phase: Custom member data)
      • job: Admin API creates, lists, archives, restores and deletes field definitions (done, phase: Custom member data)
      • job: Members store per-member custom field values (done, phase: Custom member data)
      • job: Editors edit custom field values on the member detail screen (done, phase: Custom member data)
      • job: Publishers manage and archive fields in Settings (done, phase: Custom member data)
      • job: Custom field values export in the members CSV (done, phase: Custom member data)
      • job: Custom field changes are recorded in the member history log (done, phase: Custom member data)
      • job: Operational limits cap field count and key size per member (done, phase: Custom member data)
      • job: Members submit custom fields during Portal signup (phase: Custom member data)
      • job: Segment members and target newsletters by custom field (phase: Custom member data)
    • approach: Member segmentation and filtering (NQL) (resolved)
  • need: Own the audience on the open social web

    Reach and be followed across the fediverse without renting a social platform.

    • approach: ActivityPub federation for the open social web (development)
      • job: Each publication exposes an ActivityPub actor (done, phase: Open social web)
      • job: Fediverse accounts can follow a publication and receive new posts (done, phase: Open social web)
      • job: ActivityPub app is embedded in Ghost Admin (done, phase: Open social web)
      • job: Replies, likes and reposts surface in the Ghost reader (phase: Open social web)
      • job: Follow and read other fediverse accounts inside Ghost (phase: Open social web)
      • job: Moderation controls for federated interactions (phase: Open social web)
      • job: Enable the open social web by default for all sites (beta to GA) (phase: Open social web)
    • approach: Cross-publication recommendations (validation)
  • need: Email reliably lands in the inbox

    Protect deliverability and sender reputation so sends are not wasted.

    • approach: Deliverability and suppression management (resolved)

Goal: Publishers earn sustainable revenue directly from readers

Native monetization — paid subscriptions, tiers, offers, tips and gifts via Stripe — so independent publishing is a viable business. 100% of Ghost's own revenue funds the non-profit Ghost Foundation.

  • need: Charge readers for premium access

    Gate content behind paid membership and take payment reliably.

    • approach: Stripe-powered paid subscriptions (resolved)
    • approach: Content gating by access level (resolved)
  • need: Package and price membership flexibly

    Offer multiple paid plans with distinct benefits and billing cadences.

    • approach: Tiers: multiple paid plans with benefits (resolved)
  • need: Convert with time-limited promotions

    Run discounts and offers that measurably lift conversion.

    • approach: Offers and discount codes (resolved)
  • need: Accept reader support beyond subscriptions

    Let readers give one-off support and gift memberships to others.

    • approach: Tips and one-time donations (validation)
    • approach: Gift subscriptions via gift links (validation)

Goal: Publishers make confident decisions from first-party data

Privacy-respecting analytics on content, email and membership growth — no third-party trackers — so publishers understand what is working and why.

  • need: See what content and channels drive growth

    First-party traffic and content analytics without third-party trackers.

    • approach: First-party web & content analytics (Tinybird) (development)
      • job: Tinybird analytics pipeline and datafiles wired into core (done, phase: First-party analytics)
      • job: In-Admin web traffic dashboard (done, phase: First-party analytics)
      • job: Top posts and content performance view (done, phase: First-party analytics)
      • job: Traffic sources and referrers surfaced (done, phase: First-party analytics)
      • job: Email analytics: opens, clicks and delivery per send (done, phase: First-party analytics)
      • job: Growth milestones fire at member and revenue landmarks (done, phase: First-party analytics)
      • job: Unified audience insights across web, email and members (phase: First-party analytics)
      • job: Self-hosters run analytics without a Tinybird Cloud dependency (phase: First-party analytics)
  • need: Understand email performance

    Know how each newsletter performs: opens, clicks and delivery.

    • approach: Email analytics (opens, clicks, delivery) (validation)
  • need: Know where members and revenue come from

    Attribute every signup and paid conversion to its source.

    • approach: Member attribution (signup & conversion sources) (validation)
  • need: Track and celebrate growth milestones

    Surface member and revenue landmarks to motivate publishers.

    • approach: Growth milestones (resolved)

Make yours · Made with ProductBrain