79yuuki/dotfiles/project-account-architecture

Project Account Architecture

Overview

Account structure is product architecture for attention. Design it intentionally so projects do not cannibalize each other or disappear behind the founder account.

Read references/decision-matrix.md when you need split-vs-merge criteria.

Core Output

Produce an Account Architecture Pack:

1. account inventory
2. audience and purpose per account
3. founder vs project role split
4. content lane definitions
5. governance rules

Workflow

1. Inventory the current surface

List every public surface:

• founder X/social
• project X/social
• newsletter
• blog / docs / changelog
• community / Discord / team chat / Telegram
• email aliases / contact routes

2. Define each surface's job

For each surface, assign:

• primary audience
• promise / reason to follow
• content types allowed
• call-to-action
• escalation path to deeper surface (docs, waitlist, sales, community)

If a surface has no distinct job, merge or retire it.

3. Decide split vs merge

Split accounts when:

• audience is materially different
• posting cadence is high enough
• product narrative needs its own voice
• confusion risk is high if mixed

Keep merged when:

• founder authority is the main distribution advantage
• cadence is too low for a standalone account
• operational overhead outweighs clarity gain

4. Define governance

Specify:

• owner
• approval level
• posting frequency target
• shared assets
• what never gets posted there
• handoff between founder and project accounts

Principles

• Every account needs a job
• Distribution leverage matters, but confusion costs too
• Founder voice and project voice should complement, not duplicate
• Account sprawl without cadence is dead weight

Deliverable Format

Return:

• recommended account map
• keep / merge / split / retire decisions
• content lane definitions
• governance rules
• phased migration plan if changes are needed