Skip to main content

Edition Structure

HausFlow is one codebase with multiple edition targets. This page explains how the docs and the product are organized to support that without duplicating everything.

Shared vs. Edition-Specific​

Some things in HausFlow are the same regardless of whether you are building for families, roommates, or future partners:

  • the coordination loop (assign → do → review → repeat)
  • the no-shame design standard
  • privacy and data controls
  • the real-time sync architecture
  • the notification system

These belong in shared docs and shared code. They should not be duplicated per edition.

Other things change meaningfully by edition:

  • tone (warm and supportive in Family, neutral in Roommate)
  • role names (parent/kid vs. coordinator/member)
  • governance rules (who can approve, who can see what)
  • defaults (proof requirements, auto-approval behavior)
  • feature availability

These belong in edition-specific docs and edition-specific configuration.

This Repository Is Family-First​

The current codebase is a HausFlow Family implementation. Not a generic coordination platform — a real Family app.

That means:

  • the shared doc layer describes coordination philosophy and product values
  • the Family edition docs describe the actual shipped app
  • the Roommate and Professional edition docs describe direction and architecture, not shipped features

When in doubt, assume Family unless the doc explicitly says otherwise.

Documentation Strategy​

This knowledge hub is organized so that:

  1. The homepage and getting started guides describe what is actually live today
  2. Philosophy and values docs describe the shared product standard
  3. Edition docs describe each audience and what is available to them
  4. The roadmap describes what is coming
  5. Legal and policy docs are edition-specific where required

This avoids the pattern of three near-identical doc sites with minor wording changes between them.

For Developers Working on New Editions​

When a new edition is added, the process is:

  1. Keep the shared coordination logic intact
  2. Add edition-specific configuration, tone, and role rules
  3. Write edition docs from what is actually built — not from inherited templates
  4. Update the edition overview page to mark it as live when it ships

Do not backfill aspirational docs for features that do not exist yet.