Eco Manager Documentation
Eco Manager is a self-hosted technical asset directory, credential vault, and planned remote-access platform for BMS and telecoms operations teams.
This documentation pack is intentionally lightweight. It is designed for a one or two developer team that needs strong engineering direction while still communicating clearly with technical and non-technical stakeholders.
Document Map
| Document | Audience | Purpose |
|---|---|---|
| Product Overview | Everyone | Explains what Eco Manager is, what it is not, and why it exists. |
| Roadmap | Managers, developers | Defines Alpha, Beta, and V1 scope. |
| Admin Studio | Developers, technical managers, super users | Explains the internal CRUD/admin app for managing the Universal Entity Platform. |
| Architecture Overview | Developers, technical managers | Explains the system architecture at a high level. |
| Universal Entity Platform | Developers | Core data architecture: entities, hierarchy, groups, properties, tags, relationships, templates. |
| Admin Studio Architecture | Developers | Architecture and guardrails for the Notion/Obsidian-style admin/super-user app. |
| Data Model | Developers | PostgreSQL and Drizzle-oriented schema design. |
| Security and Vault Architecture | Developers, technical managers | Encryption, tenant keys, Vault boundaries, audit, and access control. |
| Development Guide | Developers | Local setup, coding conventions, module structure, and delivery workflow. |
| Delivery Log | Everyone | Lightweight progress tracking for stakeholders. |
| ADR Template | Developers | Template for recording architecture decisions. |
| Feature Spec Template | Developers, stakeholders | Template for describing a new feature before implementation. |
Documentation Principles
- Keep docs short enough to maintain.
- Prefer living documentation over perfect documentation.
- Write for both future developers and present stakeholders.
- Record important decisions as ADRs.
- Keep implementation details close to the code, but architecture principles in docs.
- Update docs as part of feature delivery, not as a separate chore.
Recommended Workflow
For each meaningful feature:
- Create or update a short feature spec.
- If the feature changes architecture, write an ADR.
- Implement the feature.
- Update the delivery log.
- Update user-facing or architecture docs only where necessary.