Öffentlich
Vision, Produktprinzipien, MVP-Scope, Pilotmodell, Roadmap-Phasen, Architektur auf verständlichem Niveau, Compliance-Haltung.
Venuqo Project Docs · Stand: laufend gepflegt
Wie Venuqo entsteht — öffentlich nachvollziehbar.
Venuqo ist eine no-app Bestell- und Service-Schicht für Restaurants, Bars, Foodhalls und hybride Pickup-Konzepte. Diese Seite ist die kuratierte, öffentliche Projektdokumentation: Stand, Produktprinzipien, MVP-Scope, Pilotprogramm, Roadmap und wichtige Entscheidungen.
venuqo.com
Prelaunch Hub · Live
demo.venuqo.com
Stakeholder-Demo · Live
mvp.venuqo.com
Phase 2C · Live (Demo / Testbetrieb)
docs.venuqo.com
Diese Seite · kuratiert
Openbook-Prinzip
Warum diese Seite öffentlich ist
Venuqo entsteht nicht hinter verschlossenen Türen. Wir glauben, dass eine neue Service-Schicht für Hospitality nur dann Vertrauen verdient, wenn sie ihre Annahmen, Entscheidungen und ihren Stand überprüfbar macht. Diese Dokumentation ist daher bewusst öffentlich — aber kuratiert.
Sie zeigt, was wir bauen, warum wir es bauen und wo wir gerade stehen. Sie zeigt nicht jeden Zwischenstand, jede sensible Verhandlung oder interne Detailentscheidung. Beides bewusst.
Partner-only
Konkrete Pilotvereinbarungen, Menüs, Pilotzeiten, Teamfeedback, kommerzielle Konditionen, Auswertungsdetails einzelner Betriebe.
Intern
Repository-IDs, Deployment-Token, Infrastruktur-Konfiguration, individuelle Wettbewerbsanalysen, finanzielle Modellierung, sensible Verhandlungspositionen.
Diese Seite ist kuratierte öffentliche Projektdokumentation, keine vertragliche Grundlage und kein finales kommerzielles Angebot. Für verbindliche Aussagen gelten die jeweiligen Verträge und schriftlichen Vereinbarungen.
01 · Projektüberblick
Was Venuqo ist — und was bewusst nicht
Venuqo ist eine no-app Bestell- und Statusschicht für Restaurants, Bars, Foodhalls, Buffet- und Pickup-Konzepte. Gäste bestellen per Smartphone direkt am Tisch oder an einer Station — ohne App-Download. Service- und Stationsteams arbeiten in einer ruhigen Operator Console.
Venuqo positioniert sich nicht als Kassensystem-Ersatz, nicht als Delivery-Marktplatz und nicht als Reservierungssystem. Wir sind eine POS-neutrale, gastseitig wiedererkennbare Service-Schicht zwischen Gast, Tisch, Station, Team und bestehenden Systemen.
Ist
- No-App Bestell- und Statusflow für Gäste
- Operator Console für Service und Stationen
- Zwei Modi: Table Service Light und Pickup Easy Mode
- POS-neutral, integrationsoffen
- WCAG 2.2 AA / EAA als Grundanforderung
Ist nicht
- Kein Kassensystem-Ersatz
- Kein Delivery-Marktplatz
- Kein Reservierungssystem
- Kein Loyalty- oder CRM-Hub im MVP
- Kein Personalersatz, sondern Entlastung
02 · Warum Venuqo entsteht
Hospitality verdient Service-Tech, die nicht im Weg steht
Restaurant-Tech wirkt für Gäste oft wie eine Pflichtübung und für Teams wie ein zusätzlicher Stress. QR-Menüs ohne Kontext, App-Zwang, harte POS-Wechsel oder Marketplace-Kommissionen lösen einzelne Probleme, erzeugen aber neue Reibung — gerade in DACH und der Schweiz.
Venuqo entsteht aus einer einfachen Beobachtung: Bestellen, bezahlen, abholen und Service rufen sind wiederkehrende Service-Momente, die heute meist isoliert gelöst werden. Eine ruhige, wiedererkennbare Schicht zwischen Gast und Betrieb kann diese Momente verbinden, ohne die Restaurantmarke zu überlagern.
„Calm service, operational trust."
— interne Brand Essence
Für Gäste soll Venuqo wie ein vertrauter Standard wirken: „Ah, Venuqo kenne ich." Für Betreiber soll es sich wie eine ruhige operative Hilfe anfühlen, nicht wie ein weiteres Dashboard.
03 · MVP-Stand
Wo wir heute stehen
Der MVP ist live unter mvp.venuqo.com als Demo- und Testbetrieb. Die Mock-Flows wurden durch echte Supabase-Persistenz abgelöst (Phase 2B), und Phase 2C hat den Bestell- und Stationsfluss für ein erstes Pilot-Skript gehärtet. Eine kurze Zusammenfassung steht im Abschnitt unten (Aktueller Stand: Phase 2B/2C).
Phase 0 · Konzeptvertrag
Hybrid-MVP mit zwei Modi, Nicht-Ziele, EAA/WCAG als P0, Referenzprofile statt Demo-Restaurant.
Phase 1 · Blueprint
User Journeys, Datenmodell, Statusmaschine, Akzeptanzkriterien, Architekturskizze.
Phase 2 · Prototyp & Stack-Entscheidung
Click Prototype live unter demo.venuqo.com. Stack-Entscheidung getroffen: Next.js, TypeScript, Supabase, Stripe (später), Vercel.
Phase 2A · Pilot Readiness & echter MVP-Build
Abgeschlossen. Routing, Rollen-Oberflächen (Guest, Staff, Bar, Kitchen) und der MVP-Rahmen unter mvp.venuqo.com.
Phase 2B · Supabase-Persistenz
Abgeschlossen. Bestellungen werden serverseitig in Supabase gespeichert; Gast-Bestätigung überlebt Reload und direkten Wiedereinstieg über die letzte offene Bestellung pro Position. Staff/Bar/Kitchen lesen und routen persistente Daten.
Phase 2C · UI-Härtung & Demo-Reset
Aktuell live. Token-gated Reset unter /admin/reset, ruhigere Disabled-/Busy-States, Inline-Fehler, Tab-Counter, freundliche Empty-States, globaler Demo/Testbetrieb-Hinweis und 3-Sekunden-Polling mit manuellem Refresh.
Nächste Phase · Pilot Test Script + Auth/RLS
Empfohlen. Schreibbares Pilot-Test-Skript, Härtung der Auth/RLS-Grenzen für Staff/Admin und Operationalisierung des Demo-Resets vor einem realen Pilot.
03b · Aktueller Stand
Phase 2B/2C — was heute live ist
Der MVP läuft als Demo- und Testbetrieb unter mvp.venuqo.com. Hauptseite venuqo.com und Click-Prototype demo.venuqo.com sind weiterhin erreichbar. Die folgenden Punkte sind Stand heute umgesetzt — und genauso wichtig: was bewusst noch nicht.
Supabase-Persistenz
- Bestellungen werden serverseitig in Supabase gespeichert
- Gast-Bestätigung überlebt Reload und direkten Wiedereinstieg — über die letzte offene Bestellung pro Position
- Staff liest persistierte Bestellungen statt Mock-Daten
- Bar- und Kitchen-Routing arbeiten auf persistierten Items
- Statuswechsel durch Staff werden persistiert
UI-Härtung & Demo-Reset
- Token-gated Demo-Reset unter
/admin/reset - UI-Härtung für Guest, Staff und Station
- Disabled-/Busy-States, Inline-Fehler, manueller Refresh
- Tab-Counter und freundliche Empty-States
- Globaler Demo/Testbetrieb-Indikator
- 3-Sekunden-Polling plus manueller Refresh
Ehrliche Limitierungen
- Keine echte Gast-Identität / Session jenseits der jeweils letzten offenen Bestellung pro Position.
- Noch keine Staff-/Admin-Auth. Rollen-Oberflächen sind serverseitig nicht hart abgesichert.
- Keine reale Zahlung, kein POS, kein Realtime, keine Lieferlogik. Stripe und POS-Integrationen bleiben bewusst außerhalb des aktuellen Scopes.
- Reset braucht Server-Token / Service-Role oder manuelles SQL.
- RLS und Auth müssen vor einem echten Pilot weiter geschärft werden.
Nächste empfohlene Phase
Pilot Test Script (definiertes, schreibbares Test-Skript für einen kontrollierten Pilotlauf) plus Härtung der Auth/RLS-Grenzen für Staff/Admin und Operationalisierung des Demo-Resets — erst danach ist ein realer Pilot in einem Betrieb verantwortbar.
Referenz-Commits (intern): MVP-Repo 1a2eb41, Hub-Repo e4e0d30.
Diese Hashes sind Anker für die hier beschriebenen Phasen 2B/2C — sie sind keine
öffentliche API und nur für Projekt-Nachvollzug gedacht.
04 · Produktprinzipien
Sieben Leitlinien, die der MVP nicht verletzt
-
Venuqo zuerst, Restaurantbranding später
Der MVP testet Venuqo als wiedererkennbare Service-Schicht. Restaurant-Branding kommt als spätere konfigurierbare Schicht.
-
No App
Gäste öffnen Venuqo per QR oder NFC im Browser. Kein App-Download, keine App-Store-Reibung.
-
POS-neutral
Venuqo ersetzt im MVP keine Kasse. Bestehende POS-Prozesse werden nicht tief integriert, aber Order-, Payment- und Exportlogik bleiben sauber.
-
Digitale Zahlung als Kern, nicht als Zwang
Pickup arbeitet prepaid-first. Table Service Light erlaubt digitale Zahlung, behält aber Staff-Fallbacks.
-
Betriebslogik vor Featurefülle
Jede Funktion muss einen realen Serviceablauf verbessern. Schöne, aber operativ unklare Ideen bleiben draußen.
-
Menschlicher Service bleibt erhalten
Venuqo unterstützt Teams, ersetzt sie nicht. Gäste ohne Smartphone bleiben anschlussfähig.
-
Accessibility by default
WCAG 2.2 AA und EAA sind P0. Bestellen, bezahlen, Status verstehen, Service rufen — alles muss assistiv erreichbar sein.
05 · Pilotprogramm
Ein kleiner, ehrlicher Test im echten Betrieb
Der erste Pilot ersetzt kein Kassensystem, keinen Service und keinen bestehenden Restaurantprozess. Er spiegelt einen klar begrenzten Ablauf digital, damit gemeinsam geprüft werden kann, ob Venuqo im realen Betrieb tatsächlich entlastet.
Table Service Light
Casual Dining, Pub, Terrasse, Hotelbar oder definierter Restaurantbereich.
- Gäste scannen QR oder NFC am Tisch
- Mobile Webansicht ohne App
- Service und Station sehen Bestellungen
- Klassische Bestellung bleibt möglich
- Zahlung optional digital
Pickup Easy Mode
Buffet, Bar, Foodhall, Selbstabholung, Takeaway-Fenster.
- Bestellung aus begrenztem Menü
- Direkte digitale Zahlung möglich
- Ordernummer / Pickup-Code statt Buzzer
- Architektonisch im MVP angelegt
- Voller Ausbau nach erstem Pilot
Was das Restaurant beiträgt
- Klar abgegrenzter Pilotbereich (z. B. 4–8 Tische)
- Kleine Menüauswahl mit Preisen und Allergeninfos
- Eine verantwortliche Ansprechperson
- Kurze Einführung für das Team
- Ehrliches Feedback aus dem Service
Was Venuqo beiträgt
- Mobile Gästeansicht ohne App
- Operator-Ansicht für Bestellungen und Status
- Pilot-Setup für Tische, Menü, Ablauf
- Fallback-Logik für Gäste ohne Smartphone
- Gemeinsamer Review mit Empfehlung
Pilotinhalte einzelner Betriebe — Menü, Zeitfenster, Auswertungen, Teamfeedback und Konditionen — werden nicht öffentlich dokumentiert. Sie bleiben zwischen Venuqo und dem jeweiligen Pilotpartner.
06 · Roadmap
Was kommt — und was bewusst später
Bereits erreicht
- Phase 0 Konzeptvertrag
- Phase 1 Blueprint & Datenmodell
- Click Prototype unter demo.venuqo.com
- Live MVP unter mvp.venuqo.com (Demo / Testbetrieb)
- Phase 2B: Supabase-Persistenz (Guest, Staff, Bar, Kitchen)
- Phase 2C: UI-Härtung, Demo-Reset, Polling/Refresh
Aktuell & nächste Schritte
- Pilot Test Script (schreibbarer Testlauf)
- Härtung Auth/RLS-Grenzen für Staff & Admin
- Operationalisierung des Demo-Resets
- Accessibility-QA in Kernflows
- Pilotpartner-Akquise und Betriebscheck
- Pickup-Logik weiter vorbereiten
Später
- Stripe Checkout für reale Zahlungen
- Restaurant-Branding-Light (Logo, Akzent)
- Trinkgeld, Beleg-Versand, Refunds
- Pickup Easy Mode im vollen Ausbau
- Drucker- / KDS-Anbindung
- POS-Integrationen, Local Pages, Discovery
07 · Entscheidungslog
Festgehaltene Richtungsentscheidungen
Wir dokumentieren bewusst auch was wir gerade nicht tun. Jede Entscheidung ist überprüfbar und kann mit neuen Erkenntnissen revidiert werden — aber sichtbar, nicht still.
-
Ordering-first MVP
Der MVP fokussiert auf Bestellung und Statusflow, nicht auf Payment-Optimierung oder Marketing-Tools.
Status: angenommen -
Checkout als Vorschau, echte Zahlung später
Im ersten Build wird Checkout als UX-Vorschau gebaut; reale Zahlung über Stripe folgt in einem späteren, sauberen Schritt.
Status: angenommen -
Keine POS-Integration im ersten Pilot
POS-Integration kann später gezielt geprüft werden. Im ersten Pilot soll der Betrieb seine Kasse nicht anfassen müssen.
Status: angenommen -
Supabase-Persistenz als nächster echter MVP-Schritt
Ablösung der Mock-Flows durch eine relationale, portable Datenschicht. Mit Phase 2B abgeschlossen — Bestellungen, Statuswechsel und Stations-Routing arbeiten persistent.
Status: abgeschlossen (Phase 2B) -
Table Service Light zuerst, Pickup vorbereitet
Table Service Light zeigt den Venuqo-Wert am klarsten. Pickup ist datenmodell- und routingseitig angelegt, wird aber erst nach erstem Pilot voll ausgebaut.
Status: angenommen -
EAA / WCAG 2.2 AA als P0-Anforderung
Accessibility ist kein späterer Polish, sondern Eintrittsbedingung. Bei Scope-Druck werden eher andere Features gestrichen.
Status: verbindlich
08 · Architektur auf verständlichem Niveau
Wie Venuqo technisch aufgebaut ist
Venuqo wird als modularer Monolith gebaut: ein Produkt, ein Datenmodell, eine API-Schicht, mehrere Oberflächen (Gast, Operator, Admin). Das ist schneller, günstiger und leichter zu verstehen als eine Microservice-Landschaft — und lässt spätere Module trotzdem sauber zu.
Frontend
Next.js, React, TypeScript. Tailwind als Utility-Schicht. Accessible Component Patterns.
Backend
Next.js Route Handlers / serverseitige API. Businesslogik bleibt bei Venuqo, nicht im Frontend.
Datenbank
Supabase PostgreSQL. Relationales Kernmodell für Venue, Table, Station, Order, Payment.
Auth
Supabase Auth für Staff und Admin. Kein Gastlogin im MVP — Gäste nutzen QR/NFC-Kontext anonym.
Payment
Stripe Checkout, zunächst Sandbox. Sensible Logik serverseitig, nie im Frontend.
Hosting
Vercel für Preview und Produktion. Self-Hosting-Option für die Zukunft offengehalten.
Architekturprinzipien
- Businesslogik bei Venuqo: Order anlegen, Preise prüfen, Status ändern, Webhooks verarbeiten — alles serverseitig.
- PostgreSQL-portabel: Keine unnötige Bindung an Anbieter-spezifische Features im Kernmodell.
- Zwei Modi, ein Datenmodell: Table Service Light und Pickup teilen das gleiche Schema, unterscheiden sich in Regeln, nicht in Strukturen.
- Order- und Payment-Status getrennt: „Bezahlt" und „in Vorbereitung" sind unabhängige Achsen.
- Realtime nur, wo nötig: Polling oder Supabase Realtime — kein Overengineering im MVP.
09 · Compliance & Vertrauen
Barrierefreiheit, Datenschutz, Zahlungssicherheit
Venuqo ist kein Marketing-Interface, sondern ein digitaler Zugang zu Bestellung, Zahlung und Service. Compliance ist deshalb kein Anhängsel, sondern Teil des Produkts.
Accessibility (EAA / WCAG 2.2 AA)
Tastaturbedienbarkeit, Screenreader-Tauglichkeit, sichtbare Fokuszustände, ausreichende Kontraste, Reflow bei 200 % Zoom, keine rein farbliche Statusinformation, Reduced-Motion-Unterstützung. Manuelle Tests ergänzen automatisierte Checks.
Datenschutz
Gäste nutzen den MVP anonym; kein Gastlogin, kein Cross-Venue-Profil. Personenbezogene Daten werden nur verarbeitet, wo Bestellung, Zahlung oder Service-Antwort es erfordern. Kein Tracking-Layer auf dieser Dokumentationsseite.
Zahlungssicherheit
Zahlungen laufen über etablierte Payment Provider (Stripe). Karten- und Zahlungsdaten berühren Venuqo-Server nicht direkt; Webhook- Verifikation und sauberes Refund-Handling sind Pflicht vor Live-Zahlung.
Rechtlicher Rahmen
Inhalte hier sind Projektdokumentation, keine vertragliche Zusicherung. Eine öffentliche Barrierefreiheitserklärung folgt mit dem ersten echten Live-Betrieb. Pilotvereinbarungen werden individuell schriftlich geregelt.
10 · Was bewusst intern bleibt
Transparenz hat Grenzen — und das ist gut so
Venuqo dokumentiert öffentlich, was Vertrauen schafft. Wir dokumentieren bewusst nicht öffentlich, was Pilotpartner, Teammitglieder, Lieferanten oder Verhandlungen schützen muss. Diese Linie nennen wir „Openbook mit Grenzen".
Pilotpartner-Inhalte
Konkrete Restaurants, Menüs, Pilotzeiten, Auswertungsergebnisse, Teamfeedback und kommerzielle Konditionen einzelner Betriebe.
Sensible Wettbewerbsdetails
Detaillierte interne Wettbewerbsanalysen, individuelle Pricing-Strategien, Lieferantenauswahl auf Anbieterebene.
Infrastruktur-Interna
Repository-IDs, Deployment-Token, API-Keys, Provider-Konfigurationen, interne Run-Books und Incident-Details.
Personen & Verhandlungen
Persönliche Kontakte, laufende Verhandlungen mit Investoren, Partnern oder Behörden, finanzielle Modellierung im Detail.
Wenn etwas hier öffentlich erscheint, das eigentlich intern bleiben sollte, ist das ein Fehler — und wir möchten das wissen. Hinweise bitte an info@venuqo.com.