Workspace Project Roadmap — What to Tackle Next
Current State of the Codebase
| Area | Status |
|---|---|
| App Shell | ✅ Working — MainLayout, sidebar navigation, auth, theming |
| Design System | ✅ Working — ui-core (Button, ThemeToggle), ui-domain, Tailwind tokens |
| GraphQL Layer | ✅ Working — Hasura metadata, Apollo client, fragment masking, codegen |
| Fleet List | ✅ Working — First vertical slice (list vehicles from DB, card grid) |
| Database Schema | ✅ Comprehensive — 70+ tables across backoffice_, commerce_, operations_, communications_ |
| Feature Specs | ✅ Detailed — Dispatch Board, Pricing Screen, Screen Requirements, Product Requirements |
| Dashboard | ❌ Placeholder only ("Dashboard coming soon") |
| All other routes | ❌ Not implemented (Magic Upload, Trips, Bookings, Settings) |
Recommended Execution Order
The order is driven by three principles:
- Data flows downhill — Build the entities that other features depend on first.
- Deliver value early — Prioritize the feature that replaces the most manual work soonest.
- Reduce risk — Tackle the hardest technical bets early so we learn fast.
Phase 1: Fleet & Staff CRUD (Foundation Layer)
Why first? Every other feature depends on vehicles, drivers, and crew data existing in the system. The Dispatch Board needs vehicles and crew. Magic Upload needs to assign a bus. Bookings need seat maps. Without this, nothing else works.
Scope:
- [ ] Vehicle CRUD — Extend the existing Fleet List into a full detail view (create, edit, delete). Include seat map layout assignment.
- [ ] Crew Member CRUD — Create staff management (drivers, dispatchers). Include qualifications, license data, and absence/leave tracking.
- [ ] Operator Settings — Basic tenant profile and branding configuration.
Technical work:
- Establish the reusable CRUD patterns (data tables, detail drawers/pages, form validation) that every subsequent feature will reuse.
- Define the shared UI patterns: DataTable component, Form component, Detail/Edit pages.
Phase 2: Tour & Trip Management (The Catalog)
Why second? This is the core entity that everything revolves around — tours are the product. We need them in the system before we can dispatch, price, or sell them.
Scope:
- [ ] Tour Template CRUD — Create/edit/archive tour templates (title, description, itinerary stops, duration, categories).
- [ ] Trip Instantiation — Schedule concrete departures from a template (specific dates, linked vehicle + driver placeholder).
- [ ] Itinerary Builder — Visual waypoint/stop editor (list-based, not map-based in V1).
Technical work:
- Route waypoint management (
operations_route_waypoints) - Tour departure scheduling (
backoffice_tour_departures)
Phase 3: Magic Upload (The "Wow" Feature)
Why third, not first? Magic Upload outputs Tour Templates. We need the Tour Template CRUD from Phase 2 to exist first so the AI parser has a target to write into. Building Magic Upload first would mean building the template editor anyway.
Scope:
- [ ] Dropzone UI — File upload with drag-and-drop.
- [ ] AI Parser Integration — Send PDF to backend (NestJS API), receive structured extraction.
- [ ] Wizard Review Flow — The opinionated step-by-step validation wizard (Red/Orange/Green color coding per the product spec).
- [ ] Publish Flow — Approve extraction → save as Tour Template → optionally schedule a Trip.
Technical work:
- Backend AI parsing pipeline (NestJS + LLM integration)
- Import job tracking (
backoffice_import_jobs,backoffice_import_error_rows)
Phase 4: Bookings & Passenger CRM
Why here? Once tours exist and are published, bookings flow in. We need the operator to see and manage them.
Scope:
- [ ] Bookings List — Filterable data table of all bookings across trips.
- [ ] Passenger Manifest — Per-trip passenger list with seat assignments and ticket status.
- [ ] Rapid Manual Booking — Phone booking entry form (the "Herr Müller" journey).
- [ ] Passenger Profiles — 360° view with booking history and preferences.
- [ ] Visual Seat Map (Dispatcher View) — Interactive seat map for manual assignments.
Technical work:
- Commerce schema queries (
commerce_bookings,commerce_passengers,commerce_seat_reservations) - Payment integration foundation (Mollie/Klarna)
IMPORTANT
Phases 1–4 are the MVP. An operator who can manage fleet, create tours, parse PDFs, and handle bookings has a usable product. Phases 5–8 transform it from "usable" to "indispensable."
Phase 5: Dispatch Board (The Operations Brain)
Why not earlier? The Dispatch Board is the most complex UI in the system (Gantt chart, drag-and-drop, real-time subscriptions, compliance engine). It needs vehicles, crew, tours, and bookings to all exist. Building it on top of real data is dramatically more effective than building it in isolation.
Scope:
- [ ] Gantt Timeline View — Vehicles + crew on rows, service legs as blocks, 1w/2w/1m zoom.
- [ ] Drag-and-Drop Assignment — Assign resources to legs with conflict detection.
- [ ] EU Compliance Engine — Rule-based Lenk- und Ruhezeiten validation (Grey/Green/Orange/Red).
- [ ] Live Updates — Hasura GraphQL subscriptions for real-time board changes.
Technical work:
operations_service_legs,operations_leg_assignments,operations_crew_duty_logs- Compliance rule engine (likely a shared package)
Phase 6: Pricing & Costing
Why here? The pricing screen already has a detailed spec. It builds on top of tour templates and costing sheets. Shipping it after the Dispatch Board means operators can do end-to-end: create tour → dispatch → price → sell.
Scope:
- [ ] Costing Sheet Editor — Input fixed/variable costs per tour.
- [ ] Price Matrix Grid — Read-only base view + manual override mode.
- [ ] Margin Inspector — Popover showing the full price derivation stack.
- [ ] Break-Even Gauge — Dynamic PAX threshold visualization.
- [ ] § 25 UStG Tax Routing — Geospatial margin split for cross-border tours.
Phase 7: Communications Engine
Why late? Communications are downstream of everything — they trigger from bookings, dispatch actions, and disruptions. The configurable trigger system needs those source events to exist first.
Scope:
- [ ] Omnichannel Inbox — Chat-meets-ticketing hybrid UI.
- [ ] Trigger Configuration — The 5 baseline lifecycle triggers (BOOKING_CONFIRMED through BOOKING_COMPLETED).
- [ ] Template Editor — WhatsApp/Email template management in Settings.
- [ ] Disruption Broadcasts — INCIDENT_BROADCAST trigger tied to driver app incidents.
Phase 8: Executive Dashboard & Financials
Why last? The dashboard aggregates data from every other module. Building it last means every widget has real data to display. The DATEV export needs the full financial ledger to be populated by bookings and payments.
Scope:
- [ ] Tier 1: Action Items — Actual alerts + proactive/creative AI alerts.
- [ ] Tier 2: Operations Pulse — Active trips, newest bookings.
- [ ] Tier 3: Opportunities — Load gaps, resource utilization.
- [ ] Tier 4: Financial Snapshot — Historical + projected cost/profit.
- [ ] DATEV Export — SKR03/SKR04 mapping, GoBD-compliant Storno handling.
- [ ] Bank Import & Reconciliation — MT940/CAMT parsing, auto-matching.
The Critical Path
Phase 1 Phase 2 Phase 3 Phase 4
Fleet & Staff ──→ Tours & Trips ──→ Magic Upload ──→ Bookings & CRM
(Foundation) (The Product) (The "Wow") (The Revenue)
│
Phase 6 Phase 5 │
Pricing ←──────── Dispatch Board ←──────┘
(Operations Brain)
│
Phase 7 │ Phase 8
Comms ←─────┘ Executive Dashboard
Engine & Financials