Files

T

schalli 16c2d5b6af docs: complete project research for Tessera portal platform

Synthesize stack, features, architecture, and pitfalls research into
unified summary with roadmap implications and phase suggestions.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

2026-06-18 08:28:58 +02:00

10 KiB

Raw Blame History

Feature Landscape

Domain: Modular portal platform with marketplace, multi-tenancy, and workflow tool integration Researched: 2026-06-18

Table Stakes

Features users expect. Missing = product feels incomplete or unprofessional.

Feature	Why Expected	Complexity	Notes
User authentication (email/password + admin-created accounts)	Every portal needs login; without it nothing works	Medium	Foundation for all access control
Role-Based Access Control (RBAC)	Users expect permission boundaries; admins expect control	Medium	Tenant-scoped roles are critical for multi-tenancy
Multi-tenancy with data isolation	Core requirement per PROJECT.md; customers expect their data is isolated	High	Row-level security (tenant_id on every table) or schema-per-tenant
Sidebar navigation with categories	Standard portal pattern; users expect hierarchical navigation	Low	Collapsible, categorized by module type
Module activation/deactivation per tenant	Marketplace without on/off is just a list; tenants expect control	Medium	Admin toggles module visibility and access
Module licensing (admin-managed)	Core business model; tenants expect clear "you have access to X"	Medium	License = permission to activate; no payment integration yet
Responsive layout	Web apps must work on different screen sizes	Medium	Desktop-first, but must not break on tablet
Light/Dark theme	Expected in modern apps; users notice its absence	Low	CSS custom properties + toggle; store preference per user
Internationalization (i18n) - DE + EN	Core requirement; German users expect German UI	Medium	Must be baked in from day one; retrofitting i18n is painful
Basic dashboard with widgets	Central landing area gives users a "home"	Medium	Clock, search, notes, calendar as starting widgets
Session management	Users expect to stay logged in, and to be logged out on timeout	Low	Token-based with configurable expiry
Error handling and user feedback	Users expect clear feedback on actions (success/error toasts)	Low	Global notification/toast system
Loading states and skeleton screens	Without them, users think the app is broken	Low	Standard UX pattern
Search / filter within module lists	Even with 10 modules, users expect to type-to-find	Low	Client-side filter on marketplace and sidebar
User profile and settings	Users expect to change language, theme, password	Low	Per-user preferences storage

Differentiators

Features that set Tessera apart from generic portals. Not expected, but valued.

Feature	Value Proposition	Complexity	Notes
Drag-and-drop dashboard with resizable widgets	Personal workspace feel; makes dashboard actually useful vs static page	High	Use react-grid-layout or gridstack.js; persist layout per user per tenant
Widget marketplace/gallery	Users can add widgets to their dashboard from a catalog	Medium	Distinct from module marketplace; lightweight UI components
Module hot-activation without restart	Modules appear instantly after license grant; no deploy needed	High	Requires dynamic route loading or micro-frontend approach
LDAP/AD directory sync	Enterprise differentiator; auto-provision users from corporate directory	High	JIT provisioning at login + periodic group sync
Per-tenant branding/customization	Each tenant gets their own logo, color accent	Medium	Stored in tenant config; CSS variable override
Module-provided dashboard widgets	Modules can contribute widgets to the dashboard system	Medium	Module manifest declares available widgets; loose coupling
Activity feed / audit log	Transparency on who did what; compliance-ready	Medium	Event sourcing pattern; filterable by user, action, module
Admin impersonation ("view as user")	Support tool; admin can see exactly what a user sees	Medium	Scoped session with clear visual indicator
Keyboard shortcuts and command palette	Power-user acceleration; "Ctrl+K" to jump anywhere	Low	Global listener + fuzzy search over routes and actions
Onboarding wizard for new tenants	Guides new tenant admins through setup; reduces support burden	Medium	Multi-step flow: branding, users, module selection
Module dependency declaration	Module A requires Module B; platform enforces this	Low	Manifest-level declaration; block activation if dependency missing
Notification center	Unified inbox for system events, module alerts, admin messages	Medium	WebSocket or SSE for real-time; persisted read/unread state
Desktop wrapper (Electron/Tauri)	Installable app feel; taskbar presence, native notifications	Medium	Tauri preferred (smaller binary, Rust-backed)

Anti-Features

Features to explicitly NOT build. These add complexity without proportional value for Tessera's use case.

Anti-Feature	Why Avoid	What to Do Instead
Third-party module SDK / developer portal	Massive complexity (sandboxing, review pipeline, versioning); only own modules planned	Build a clean internal module contract; open up later if demand arises
Payment/billing integration	Out of scope per PROJECT.md; adds regulatory and UX burden	Admin-managed license grants; add Stripe/payment only when selling externally
Real-time collaboration (multiplayer editing)	Workflow tools are typically single-user operations; CRDT/OT is enormously complex	Each module handles its own data; no shared editing state
AI/ML-powered recommendations	"Suggested modules" adds little value with a small catalog; ML overhead is huge	Manual curation and categories; maybe simple "popular modules" counter later
Native mobile app	Web-first + desktop wrapper covers the use case; mobile adds two platforms to maintain	Responsive web design; PWA if truly needed later
Complex workflow orchestration engine (BPMN)	Tessera modules ARE the tools; building a meta-workflow layer is a product in itself	Each module handles its own workflow; cross-module orchestration is future scope
White-label/full-rebrand per tenant	Different from "per-tenant branding"; full white-label means separate builds, domains, assets	Offer logo + accent color customization; not full theme overhaul per tenant
Plugin sandboxing (iframe/WASM isolation)	Only own modules are deployed; sandboxing is for untrusted third-party code	Modules are trusted first-party Docker containers; share the same runtime
Social features (comments, reactions, @mentions)	Not a collaboration tool; adds social complexity without clear workflow value	Keep modules focused on their task; add module-specific notes if needed
Granular per-field permissions	RBAC at role/module level is sufficient; field-level ACL is enterprise overkill	Role -> Module access mapping; maybe per-module "read/write/admin" tiers

Feature Dependencies

Authentication -> RBAC -> Multi-Tenancy (each layer builds on the previous)
Multi-Tenancy -> Module Licensing (licenses are tenant-scoped)
Module Licensing -> Module Activation (can't activate without license)
Module Activation -> Marketplace UI (marketplace displays activation state)
Dashboard Framework -> Widget System -> Drag-and-Drop Layout
Dashboard Framework -> Module-Provided Widgets (modules contribute to dashboard)
i18n Framework -> All UI Components (must be in place before building UI)
Theme System -> All UI Components (CSS variables must exist before components)
LDAP Integration -> User Management (extends, does not replace manual management)
Notification Center -> Module Events (modules emit events to notification system)
Sidebar Navigation -> Module Registry (sidebar reflects activated modules)

MVP Recommendation

Prioritize in this order:

Authentication + RBAC + Multi-Tenancy - Foundation; nothing works without it
Sidebar navigation + Module registry - Portal shell; gives the app structure
i18n framework (DE + EN) - Must be first, before building UI text
Theme system (light/dark) - Must be first, before building styled components
Marketplace UI with licensing/activation - Core business logic
Basic dashboard with static widgets - User home; clock, search, notes
Domaincheck module - First real module; validates the entire module architecture
Drag-and-drop dashboard - Differentiator; upgrade from static layout

Defer:

LDAP integration: High complexity, not needed for initial internal use (manual user creation suffices)
Desktop wrapper: Adds build pipeline complexity; browser works fine initially
Notification center: Useful but not critical until multiple modules exist
Admin impersonation: Support tool; not needed until external customers arrive
Onboarding wizard: Only valuable with external tenants; internal users get manual setup

10 KiB Raw Blame History