Platform Vision
Author: Julian Brüning Status: ACTIVE VISION // DRAFT Inspiration: Lambus, Lambus AI, MagicMiles
IMPORTANT
This document was originally conceived as a forward-looking thought experiment, but it now actively guides our architectural boundaries (such as event-driven domains) and strategic roadmap. While Horizons 2 and 3 remain aspirational, the structural groundwork for them dictates how we build Horizon 1 today.
NOTE
Relationship to Feature Subsets: This document describes the strategic timeline — when and why we build each capability. STRATEGY_feature-subsets.md describes the commercial packaging — what the customer buys as modular wedge products. Feature subsets is the authoritative routing table for per-feature specifications; this document provides the strategic narrative that guides feature prioritization.
Timeframe & Execution Horizons
To prevent "vision inflation" from distracting the core engineering goals, the platform evolution is strictly grounded in execution phases:
| Marker | Meaning |
|---|---|
[v0.1] | The absolute minimum feature set required to transition the first Patchwork Operators off Excel/WhatsApp. |
[v0.2] / H1 | The "Operator-in-a-Box" phase. Establishing the core system, powered by Concierge Onboarding. |
[future] / H2 | The "AI Workforce" phase. Transitioning into outcome-based pricing and Product-Led Growth (PLG). |
[vision] / H3 | The Ground Transportation OS phase. Vertical-agnostic domain primitives. |
NOTE
These execution horizons are not 1:1 mapped to BSFZ Vorhaben. The four BSFZ funding clusters group research problems by technical theme (pricing uncertainty, distributed consistency, LLM reliability, privacy-aware analytics) and each spans multiple horizons. See bsfz-strategie.md §Vorhaben-Clustering.
Executive Summary
Busflow starts as a verticalized SaaS for SMB bus tour operators in the DACH region. The architecture — modular bounded contexts, event-driven communication, multi-tenant isolation, and an agent-first operating model — ensures that today's MVP doesn't become tomorrow's legacy monolith.
The ultimate go-to-market trajectory moves from High-Touch Concierge Sales (to dislodge entrenched incumbents) toward a self-serve Product-Led Growth (PLG) motion driven by autonomous onboarding.
H1 — Operator-in-a-Box (The "Shopify Moment")
Thesis
Most bus tour operators in DACH have no meaningful digital presence. Busflow delivers a complete branded digital presence in 24 hours.
What the Operator Gets
| Capability | Powered By | Timeframe |
|---|---|---|
| Core Entity CRUD (Tours, Vehicles, Crew) | Backoffice context | [v0.1] |
| Branded booking engine embedded on website | Commerce context | [v0.1] |
| Modern payment processing (Apple Pay, Klarna, SEPA) | Mollie Marketplace integration | [v0.1] |
| Digital Wallet passes (Apple/Google Wallet) with push updates | Ticket fulfillment pipeline | [v0.1] |
| Offline-capable digital tickets with cryptographic validation (CBOR/CWT/COSE) for low-connectivity boarding | Ticket pipeline + Operations context | [v0.1]–[v0.2] |
| Kalkulations-Engine — cost planning (Vorkalkulation), dynamic pricing, contribution margin validation, § 25 UStG tax automation | Backoffice + Commerce contexts | [v0.1]–[v0.2] |
| Automated passenger communication | Communications context (WhatsApp, Email) | [v0.2] |
| Branded passenger portal (PWA) | Passenger app + Communications | [v0.2] |
| Driver-facing execution hub — offline PWA, QR boarding, digital manifests, onboard POS | Operations context | [v0.2] |
| Live ETA tracking — secure "Where is my Bus?" passenger web link with real-time maps | Operations context (Telemetry pipeline) | [v0.2] |
The "Magic Launch" Flow & Concierge Bridge
Right now, the industry is terrified of data migration and system changes. Therefore, our H1 Go-To-Market is Concierge Onboarding.
We execute the "Magic Launch": The operator drops us an itinerary email, and we run the AI data extraction locally, setting up their tenant, booking page, and checkout funnel for them. This creates day-one value without asking the operator to learn new software.
Over time, this Concierge motion will be codified into the software, paving the way for the Product-Led Growth (PLG) model where operators self-onboard.
Zero-Integration Onboarding (Email-as-API)
Operators don't need to learn a new UI or build API integrations. They forward existing communications to smart Busflow addresses:
upload@<operator>.busflow.app— Forward supplier itineraries (PDFs or emails). The system auto-parses them and createsTourTemplatesready for review.bookings@<operator>.busflow.app— Forward scattered passenger booking requests; the system extracts passenger intent and data to create draftBookings.
This eliminates the #1 objection from Patchwork Operators: "We can do this for free in our inbox." The counter: "Can your inbox read the emails and generate the tours?"
Strategic Prototyping (Optional n8n → Core Graduation)
As a greenfield project, we may use tools like n8n to prototype disposable integration workflows (Wallet Pass demos, WhatsApp sandbox flows) before building durable services. We do not plan core product architecture around n8n. Validated customer-facing workflows graduate into dedicated NestJS/BullMQ/Communications services for production stability, observability, typed contracts, and code review. No n8n workflows are in production today — this section documents an optional validation tactic, not a platform dependency.
H2 — AI Workforce (The Hybrid Intelligence Model)
Thesis
The travel industry doesn't need to learn more software interfaces — it needs fewer tasks. Busflow will begin selling outcomes, not just seats.
We accomplish this through a Hybrid Rules/AI Engine. Pure GenAI is too unpredictable for DOT compliance and accounting; pure rules engines are too rigid for modern UX. By layering an AI Agent UX on top of a deterministic rules engine (e.g., calculating EU-561 rest hours), we achieve structural integrity and creative flexibility.
Intelligent Agents
The AI-powered actors that automate specific domain tasks through the Hybrid Rules/AI approach:
| Agent | What It Does | Timeframe |
|---|---|---|
| Upload Agent | Analyzes supplier PDFs (LLM), maps them to strict DB templates (Rules), drops them in a human-review queue. | [v0.2] |
| Compliance Copilot | Monitors EU-561 hours in the background (Rules Engine). Flags issues and suggests schedule rearrangements (AI Copilot). | [v0.2] |
| Crisis Agent | Detects a delay via telematics data. Automatically drafts a passenger SMS update and recalculates driver compliance. | [future] |
| Sales Agent | Natural language WhatsApp bot checking live Postgres inventory logic. | [future] |
| Finance Agent | Full-cycle tour profitability — pre-departure cost planning (Vorkalkulation), § 25 UStG tax automation, post-departure Soll/Ist reconciliation (Nachkalkulation), and deterministic DATEV export. | [v0.2]–[future] |
Platform Capabilities
Non-agent systems that extend the operator's digital surface:
| Capability | What It Does | Timeframe |
|---|---|---|
| Collaborative Trip Planning | Multi-dispatcher CRDT-based concurrent editing of tour templates and live charter planning. | [v0.2] |
| Human-AI Co-Creation | AI agents participate as live cursors in CRDT-based trip planning sessions, contributing route optimizations and cost calculations in real-time alongside human dispatchers. Requires Agentic Undo, provisional state awareness, and intent conflict resolution. | [future] |
| Communication Decision Engine | Resolves cross-context notification conflicts via Supersession Rules and Freshness Gates before they reach the passenger. | [v0.2] |
| Omnichannel Inbox | Consolidates WhatsApp, Email, and SMS into a single dispatcher console with AI-drafted contextual responses. | [v0.2] |
| Trigger-Based Automation | Event-driven passenger messages — T-24h pre-departure reminders, post-trip review requests, and lifecycle notifications. | [v0.2] |
| B2B Agency Portal | White-label API portal for partner travel agencies to book directly on commission. | [v0.2] |
Agentic Governance
Busflow operates as an agent-first company. The governance layer ensures AI agents function as a reliable "virtual workforce" across engineering, product, and operations — without cascading failures. Bounded-context-scoped agent access control via MCP restricts each agent's blast radius. A multi-stage review pipeline (Self-Review → Supervisor → Founder) catches errors before they propagate. See agentic-led-company-spec.md and ADR-020 for the full specification.
Customer Intelligence (Privacy-First Analytics)
As operator adoption grows, Busflow aggregates cross-context behavioral signals to deliver data-driven insights — under strict DSGVO compliance. This maps to the fifth product pillar defined in PRODUCT_identity.md.
| Capability | What It Does | Timeframe |
|---|---|---|
| 360° Customer Profile | Event-sourced behavioral analytics (booking frequency, lifetime value, churn risk) across four bounded contexts with privacy-preserving aggregation and GDPR-safe tombstone deletion. | [future] |
| Consent-Aware Recommendations | Collaborative filtering ("passengers who booked Nordsee also booked Ostsee") with machine-unlearning support for consent withdrawal across multi-tenant boundaries. | [future] |
| Generative Engine Optimization | Dual-paradigm tour landing pages optimized for both traditional crawlers (schema.org BusTrip/TouristTrip) and LLM-based retrieval systems (AI Overviews, Perplexity). | [future] |
| Privacy-Preserving Conversion Analytics | First-party funnel measurement for embedded booking widgets without third-party cookies, using an API-agnostic architecture resilient to quarterly Privacy Sandbox changes. | [future] |
H3 — Ground Transportation OS (The Long-Term Moat)
Status: Long-term vision. Not in active development. Documented strictly to ensure our bounded contexts and domain primitives don't paint us into a corner. For conditional, market-dependent feature ideas (network effects, demand intelligence, charter collaboration), see Future Ideas & Visionary Concepts.
Thesis
If H1 captures operators and H2 automates them, H3 redefines what Busflow is. The core domain primitives — Vehicles, Drivers, Routes, Passengers, Compliance, Payments — are not bus-tour-specific. They describe any scenario where people move on roads.
The OS Abstraction
Busflow ultimately becomes the operating system for ground transportation. Scheduled lines, corporate shuttles, school transport, event shuttles — every vertical shares the same abstract primitives. The bounded-context architecture built in H1/H2 should not foreclose this expansion. Naming, data models, and domain abstractions must remain transport-vertical-agnostic wherever possible without adding premature complexity.
Explicit Non-Goals
Strategic boundaries that prevent scope creep and protect startup velocity. For the full competitive landscape and incumbent analysis, see STRATEGY_competitive-landscape.md.
- ❌ Consumer travel planning app — Lambus territory. Our B2C surface serves the operator's passengers, not independent travelers.
- ❌ Proprietary accounting system — We integrate with DATEV; we do not replace the Steuerberater's toolchain.
- ❌ Scheduled public transit (Linienverkehr) — RATIOsoftware's domain. Our primitives apply, but regulatory and tendering complexity make this a distraction.
- ❌ Bespoke per-customer customization — We build configurable product, not consultancy-driven bespoke implementations (SIO territory).
- ❌ Website hosting, brand design & marketing services — Busflow provides an embeddable booking engine and branded passenger portal, not a website builder, CMS, or design agency. Operators own their website, logo, and corporate identity. We integrate into their digital presence; we do not create it. White-label parameters (accent color, logo upload, custom domain) are product configuration, not bespoke design work.
- ❌ Multi-entity corporate structures — Kuschick-scale holding company hierarchies are not in scope for current horizons.
NOTE
Architectural Hedge: While multi-entity structures and international market expansion are product-level non-goals today, the bounded-context architecture and multi-tenant data model must not create structural barriers to supporting them if market signals change. Infrastructure preparation for these "what-ifs" is an ongoing architectural concern, not a feature commitment.