docs: add productization roadmap

2026-03-26 10:52:10 +01:00
parent 08971abc28
commit 8926d6860c
1 changed files with 215 additions and 0 deletions
--- a/PRODUCTIZATION_ROADMAP.md
+++ b/PRODUCTIZATION_ROADMAP.md
@@ -0,0 +1,215 @@
+# Productization Roadmap
+
+## Goal
+
+Turn the current TUBCO-specific onboarding/offboarding portal into a reusable company portal product while preserving the current TUBCO deployment as a stable customer-specific baseline.
+
+Current branch roles:
+
+- `main`: current TUBCO-oriented working baseline
+- `product_company_portal_foundation`: generic product-development branch
+
+## Core Product Principles
+
+1. Do not build "TUBCO with exceptions".
+2. Separate platform core from company configuration.
+3. Start as single-tenant configurable, not full multi-tenant.
+4. Make branding and document identity admin-managed, not code-managed.
+5. Add new business apps only after the core platform layer is standardized.
+
+## Product Layers
+
+### 1. Platform Core
+
+Reusable across all customer deployments:
+
+- authentication
+- roles and permissions
+- page shell and navigation
+- audit log
+- backup and recovery
+- integrations framework
+- translations
+- document engine
+- app registry
+
+### 2. Company Configuration
+
+Per deployment / per company:
+
+- portal title
+- company display name
+- logos
+- favicon
+- brand colors
+- support/contact email
+- legal text
+- default language
+- PDF letterhead
+- email sender labels
+- notification routing defaults
+
+### 3. Business Apps
+
+Examples:
+
+- onboarding / offboarding
+- welcome emails
+- asset return
+- approvals
+- leave / request flows
+- checklists
+- document workflows
+
+## Delivery Strategy
+
+### Phase 0. Freeze Current Customer Baseline
+
+Status: completed
+
+Purpose:
+
+- keep the current TUBCO state stable
+- allow future customer-specific fixes without mixing them with productization work
+
+Snapshot commit:
+
+- `08971ab` `snapshot: preserve current tubco portal baseline`
+
+### Phase 1. Product Core Standardization
+
+Status: next
+
+Purpose:
+
+- remove hardcoded company identity from the platform surface
+- introduce config-driven branding and document identity
+
+Deliverables:
+
+1. `PortalBranding` or `TenantConfig` model
+   - portal title
+   - company name
+   - logo
+   - favicon
+   - primary / secondary colors
+   - support email
+   - default language
+   - PDF letterhead file
+   - legal / imprint / privacy text
+
+2. Branding management UI
+   - super-admin/admin controlled
+   - editable from frontend
+
+3. Shared context layer
+   - inject branding into templates
+   - replace hardcoded TUBCO title/logo references
+
+4. Tenant-aware document identity
+   - letterhead path from config
+   - company display name from config
+   - footer/legal text from config
+
+5. Documentation updates
+   - product setup flow
+   - branding flow
+   - PDF/letterhead override behavior
+
+### Phase 2. App Registry and Navigation
+
+Purpose:
+
+- stop hardcoding app cards and app visibility in the homepage template
+
+Deliverables:
+
+- app registry model or registry config
+- title / subtitle / icon / route / required capability / enabled flag
+- homepage and navigation driven by registry data
+- ability to enable/disable apps per deployment
+
+### Phase 3. Trial Mode Lifecycle
+
+Purpose:
+
+- allow limited-time test environments for demos and sales
+
+Deliverables:
+
+- trial flag
+- `trial_expires_at`
+- trial banner
+- safe default integrations behavior
+- cleanup command / scheduled deletion
+- DB/media cleanup policy
+
+### Phase 4. New Business Apps
+
+Only start after phases 1-3 are stable.
+
+Candidate apps:
+
+- asset management
+- leave / absence requests
+- approval workflows
+- internal purchase requests
+- visitor onboarding
+- contractor onboarding
+- policy acknowledgements
+
+## Recommended Deployment Model
+
+Initial product model:
+
+- single-tenant configurable deployment
+- one company per deployment
+- shared codebase
+- company identity controlled through admin-managed config
+
+Do not start with:
+
+- true multi-tenant shared-data SaaS
+
+Reason:
+
+- tenant isolation affects auth, media, PDFs, routing, backups, audit, and cleanup
+- it is much more complex than the current product stage requires
+
+## What Must Be Removed From Hardcoded Product Core
+
+Examples already identified:
+
+- `TUBCO Onboarding & Offboarding Portal`
+- logo asset references
+- invitation email wording mentioning TUBCO
+- welcome-email defaults mentioning TUB/CO
+- fixed letterhead file assumptions
+
+These should move into configuration progressively, not all at once in one risky rewrite.
+
+## Immediate Next Slice
+
+Implement first:
+
+1. `PortalBranding` model
+2. branding management page
+3. shared branding context processor
+4. replace header/logo/title references on:
+   - home
+   - shared header
+   - login/auth pages
+5. make PDF letterhead configurable
+
+This is the first productization slice because it gives:
+
+- generic portal identity
+- customer-specific configurability
+- a cleaner base for every future app
+
+## Guardrails
+
+- keep current TUBCO defaults as the initial values
+- keep migrations backward-compatible
+- update both wiki and developer handbook for every architecture change
+- snapshot at the end of each major phase