# 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: 1. **Authentication + RBAC + Multi-Tenancy** - Foundation; nothing works without it 2. **Sidebar navigation + Module registry** - Portal shell; gives the app structure 3. **i18n framework (DE + EN)** - Must be first, before building UI text 4. **Theme system (light/dark)** - Must be first, before building styled components 5. **Marketplace UI with licensing/activation** - Core business logic 6. **Basic dashboard with static widgets** - User home; clock, search, notes 7. **Domaincheck module** - First real module; validates the entire module architecture 8. **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 ## Sources - [WorkOS: Multi-tenant RBAC design](https://workos.com/blog/how-to-design-multi-tenant-rbac-saas) - [Logto: Build a multi-tenant SaaS application](https://logto.medium.com/build-a-multi-tenant-saas-application-a-complete-guide-from-design-to-implementation-d109d041f253) - [Cloudscape Design System: Configurable Dashboard](https://cloudscape.design/patterns/general/service-dashboard/configurable-dashboard/) - [FreeCodeCamp: Type-safe plugin architecture in React](https://www.freecodecamp.org/news/how-to-design-a-type-safe-lazy-and-secure-plugin-architecture-in-react/) - [Backstage.io: Plugin-based developer portal](https://backstage.io/) - [AppMaster: Audit logging for internal tools](https://appmaster.io/blog/audit-logging-internal-tools-activity-feed) - [Frontegg: SaaS Multitenancy components](https://frontegg.com/blog/saas-multitenancy) - [Medium: Node.js Plugin Architecture with ES Modules](https://medium.com/codeelevation/node-js-plugin-architecture-build-your-own-plugin-system-with-es-modules-5b9a5df19884) - [DevelopersVoice: Plugin-ready modular monolith](https://developersvoice.com/blog/dotnet/building_plugin_ready_modular_monolith/) - [Gridstack.js: Interactive dashboards](https://gridstackjs.com/)