docs: add productization roadmap
This commit is contained in:
Md Bayazid Bostame
215
PRODUCTIZATION_ROADMAP.md
Normal file
215
PRODUCTIZATION_ROADMAP.md
Normal file
@@ -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
|
||||||
Reference in New Issue
Block a user