# Productization Roadmap

## Goal

Turn the current TUBCO-specific onboarding/offboarding portal into Workdock, a reusable company portal product, while preserving the current TUBCO deployment as a stable customer-specific baseline.

Current branch roles:

- `main`: current TUBCO customer 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.
6. Prefer inline editing for lightweight profile and configuration data, but keep explicit forms for sensitive or high-risk settings.

## 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:

- former TUBCO-specific portal title kept only as historical baseline context
- logo asset references
- invitation email wording mentioning TUBCO
- historical product text references that still describe the original TUBCO baseline
- 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 customer deployment values stable while generic product defaults move to Workdock
- keep migrations backward-compatible
- update both wiki and developer handbook for every architecture change
- snapshot at the end of each major phase

## Shared UI Pattern: Inline Editing

Use inline editing as a platform pattern where it improves speed without weakening clarity or safety.

Good candidates:

- user profile and contact data
- company config sections
- branding text and non-sensitive metadata
- low-risk app-registry metadata

Do not use it by default for:

- credentials and secrets
- integrations with side effects
- destructive actions
- multi-step workflow forms
- settings that need heavy validation or confirmation

Preferred implementation style:

- section-level inline editing
- explicit `Bearbeiten`, `Speichern`, `Abbrechen`
- no noisy per-field autosave
- clear view mode and edit mode separation

Reason:

- keeps Workdock faster and more product-grade
- avoids large admin-style forms for simple edits
- still preserves reliable validation and safer change boundaries