schalli/tessera-ctl
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 14 Wiki Activity

docs: complete project research for Tessera portal platform

Browse Source 
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>
This commit is contained in:
Schalli
2026-06-18 08:28:58 +02:00
parent 77ca2421ca
commit 16c2d5b6af
5 changed files with 1082 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.planning/research/FEATURES.md
+112
View File
@@ -0,0 +1,112 @@
# 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/)