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

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

Delivered:

• generic branding model and management UI
• shared branding context across shell/auth/pages
• configurable favicon, logo, sender display, footer/legal text, and PDF letterhead
• company-domain-driven email defaults and validation
• platform vs company admin separation for product-level controls

Phase 2. App Registry and Navigation

Status: completed

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
• role-based app visibility and section grouping
• drag-and-drop ordering with filter-safe behavior

Phase 3. Trial Mode Lifecycle

Status: completed

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

Delivered:

• platform-only trial management UI
• shared trial banner and expiry enforcement
• integration restriction during trial mode
• cleanup/verification management commands

Phase 4. New Business Apps

Status: next

Only start after phases 1-3 are stable and the workflow regression suite is green.

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

1. restore and keep green the onboarding/offboarding regression suite
2. extend dynamic onboarding configuration:
   • field visibility
   • section visibility
   • guarded required/optional controls
3. remove remaining hardcoded customer/product leakage from docs, fixtures, and fallback assets
4. continue security and observability hardening before the next business app

This is the next productization slice because it gives:

• reliable core workflow behavior
• safer deployment-neutral product defaults
• a configurable onboarding experience for future customers

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