workdock-platform/PRODUCTIZATION_ROADMAP.md

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