SalesFam Documentation
This is the technical documentation for SalesFam — an all-in-one Marketplace, Sales Tracker, and CRM platform bridging companies with independent sales representatives.
It is generated from the SalesFam MVP Blueprint and kept as source-controlled Markdown so it evolves alongside the codebase.
Start with the Contribution Guide — how features are picked up, the order the work happens in, and how frontend and backend coordinate through the API contract.
How this documentation is organized
The content follows the same structure the Blueprint itself proposes: nine numbered chapters, from the high-level product scope down to the implementation plan and technology stack.
| # | Chapter | Content |
|---|---|---|
| 01 | Blueprint & MVP Scope | Product concept, core panels, onboarding requirements, payment flows |
| 02 | Functional Requirements (FRS) | What the system must do, grouped by Functional Requirement (FR) |
| 03 | Domain & Data Model | Core entities and relationships, independent of storage/API |
| 04 | Database Design | Tables, keys, constraints, indexes |
| 05 | API Endpoints | Request/response contracts for each endpoint |
| 06 | Security | Controls required to protect each functional area |
| 07 | Architecture | Components and request flow |
| 08 | Implementation Plan | Ordered, dependency-aware build tasks |
| 09 | Technology Stack | Approved frontend, backend and infrastructure choices |
Chapters 02 through 08 are organized by Functional Requirement (FR-01, FR-02, ...), not the other way around — each FR gets its own subfolder inside every chapter that applies to it. Right now only FR-01 — IAM / Authentication is fully specified end to end; FR-02 — Merchant & Product Management has its scope defined but its sub-requirements are not written yet. New FRs (FR-03 and onward) get added the same way, one at a time, without reorganizing anything that already exists.
Adding a new Functional Requirement
The Functional Requirements chapter (02) is the one meant to grow continuously as the product evolves. Instead of hand-writing a new Markdown file with the right frontmatter, folder and numbering, run:
npm run new:fr
This starts a small local form (in your browser) where you fill in the requirement's Trigger, System shall behavior, state transition and Acceptance Criteria. It creates the file in the right place automatically, correctly numbered. See Functional Requirements → Adding a new FR for details.
The other chapters (Domain Model, Database Design, API, Security, Architecture, Implementation Plan) are written as regular technical documentation and go through a normal pull request, once a given FR reaches that stage of design.
Contributing
Documenting a Functional Requirement is the first of three steps every feature goes through — the requirement, then the OpenAPI contract, then the code. The Contribution Guide covers the whole sequence: how work is tracked on the Project board, how frontend and backend agree the contract before either starts building, the order pull requests are merged in, and who owns the tests.