Pizza Blitz – Website mit eigenem Bestellsystem (Stripe → Kasse → Telegram)
Pizza Blitz ist ein fiktiver Lieferdienst, an dem ich zeige, wie ein eigenes Bestellsystem ohne Lieferplattform funktioniert. Die Website nimmt Bestellungen entgegen, kassiert per Stripe, bereitet den Datensatz für die WinOrder-Kasse auf und meldet jede Bestellung per Telegram. Die komplette Kette ist mit Testkarte durchgetestet.
- Zeitraum
- Sommer 2026
- Status
- Online als Prototyp – Zahlung im Stripe-Testmodus, noindex
- Art
- Prototyp, fiktiver Betrieb
- Branche
- Gastronomie / Lieferdienst
- Umfang
- One-Pager + Impressum/Datenschutz + Bestell-Backend
- Technik
- HTML/CSS/JS, GSAP, Cloudflare Worker + KV, Stripe Checkout
Prototyp: funktionsfähig gebaut und getestet, aber kein Auftrag eines zahlenden Kunden. Zahlungen laufen im Testmodus.
Ausgangslage
Viele Pizzerien zahlen bei jeder Bestellung über Lieferplattformen eine Provision und bekommen dafür nicht einmal die Kundendaten. Ich wollte zeigen, dass ein eigenes Bestellsystem für einen kleinen Betrieb machbar ist – ohne eigenen Server, ohne monatliche Softwaremiete und ohne Abhängigkeit von einer Plattform. Mehr dazu unter Online-Bestellsystem.
Der Ausgangspunkt war ein exportiertes Website-Bundle aus einem Baukasten: eine proprietäre Laufzeitumgebung, die sich nicht sauber bearbeiten ließ. Statt daran herumzuflicken, habe ich die Seite komplett als echtes HTML, CSS und JavaScript neu gebaut – mit Speisekarte, Warenkorb und Kasse als festem Bestandteil.
Wichtig war mir, dass die Bestellung nicht in einer E-Mail endet, sondern dort landet, wo die Küche arbeitet: in der Kasse. Deshalb bereitet das Backend jede bezahlte Bestellung als Datensatz für WinOrder auf, ein in der Gastronomie verbreitetes Kassensystem. Das gleiche Prinzip nutze ich beim Antepli-Konzept – dort mit Küchen-Ticket statt Kasse.
Ziele
6 Ziele, an denen sich das Projekt messen lässt
- Bestellungen ohne Plattform-Provision direkt über die eigene Website annehmen
- Zahlung sicher abwickeln – der Server rechnet die Preise, nicht der Browser
- Bezahlte Bestellungen automatisch für die WinOrder-Kasse aufbereiten
- Sofortige Benachrichtigung des Betriebs per Telegram
- Öffnungszeiten und Annahmeschluss technisch erzwingen, nicht nur anzeigen
- Schnelle, barrierearme Seite, die auch am Handy Lust auf Bestellen macht
Lösung
Was gebaut wurde – Baustein für Baustein
One-Pager mit klarer Bestellführung
Hero, Highlights, „In drei Schritten zur heißen Pizza“, Speisekarte, Über uns, Bestell-Tracker, Bewertungen und Kontakt – alles auf einer Seite, der Warenkorb ist von überall erreichbar.
Warenkorb mit Persistenz
Der Warenkorb liegt im localStorage und übersteht Seitenwechsel und Reloads. Mengen, Zwischensumme und Lieferart werden direkt im Warenkorb gepflegt.
Kasse über Stripe Checkout
Die Kasse öffnet ein Formular mit Kontakt- und Lieferdaten und leitet zu Stripe Checkout weiter. Nach der Zahlung kommt der Gast auf einen Bezahlt-Screen mit Bestellnummer und Artikelliste zurück.
Server als Preiswahrheit
Preise und Öffnungszeiten liegen in einer Menü-Datei auf dem Worker. Der Browser schickt nur Artikel-IDs und Mengen; der Server rechnet alles neu. Manipulierte Preise sind damit ausgeschlossen.
Webhook → WinOrder-Datensatz → Telegram
Stripe meldet die Zahlung an einen Webhook mit HMAC-Signaturprüfung. Erst dann wird die Bestellung als bezahlt markiert, als WinOrder-Datensatz im KV abgelegt und per Telegram gemeldet.
Blitz-Tracker mit Zeitlogik
Ein Bestell-Tracker zeigt den Status und eine geschätzte Zeit (Lieferung 35 Minuten, Abholung 20 Minuten). Unbezahlte Bestellungen werden abgewiesen; bei einer frischen Bestellung wartet der Tracker kurz auf den Webhook.
Öffnungszeiten erzwungen
Außerhalb der Öffnungszeiten heißt der Button „Geschlossen“, und der Server lehnt Bestellungen ab. 15 Minuten vor Schluss ist Annahmeschluss – in Bremer Zeit, unabhängig von der Uhr des Gastes.
Shop-Funnel-Analytics
Über mein eigenes Analytics-System werden product_view, add_to_cart, checkout_start, begin_payment und purchase gezählt – nur nach Einwilligung, ohne Google.
Design
Die Farbwelt ist bewusst appetitlich und laut: ein sattes Rot für Aktionen, ein warmes Gelb als Akzent und ein cremefarbener Hintergrund statt kaltem Weiß. Für Text auf Creme habe ich die Rot- und Grüntöne nachjustiert, bis der Kontrast WCAG-sicher war.
Typografisch trifft die Source Serif 4 in Überschriften auf die Instrument Sans im Lauftext. Die Serife bringt Handwerk und „seit 1990“ ins Bild, die Grotesk hält Speisekarte, Preise und Formulare gut lesbar. Beide Schriften sind self-hosted.
Die Bewegung kommt von GSAP mit ScrollTrigger: Sektionen gleiten beim Scrollen ein, der Warenkorb rutscht als Schublade herein. Wer reduzierte Bewegung eingestellt hat, sieht alles sofort und ohne Animation.
Technik
9 Bausteine – und warum genau diese
Vanilla HTML/CSS/JS
Kein Framework, kein Build-Schritt – die Seite lädt schnell und bleibt jahrelang wartbar.
Cloudflare Worker + KV
Bestellungen ohne eigenen Server, kostenlos im Free-Plan; Bestelldaten liegen 14 Tage im KV und verfallen dann automatisch.
Stripe Checkout + Webhook
Zahlung auf einer gehosteten Stripe-Seite (kein Kartenkontakt auf der eigenen Website); der Webhook bestätigt die Zahlung serverseitig mit HMAC-Signatur.
WinOrder-Aufbereitung
Bezahlte Bestellungen werden als Datensatz für das Kassensystem abgelegt – die Übergabe in die Küche ist vorbereitet.
Telegram Bot API
Jede Bestellung landet sofort als Nachricht auf dem Handy des Betriebs – ohne App-Entwicklung.
Origin-Härtung
Der Checkout-Endpunkt antwortet nur der eigenen Domain; fremde Aufrufe bekommen 403.
GSAP + ScrollTrigger (self-hosted)
Weiche Scroll-Animationen ohne externe Requests; lokal ausgeliefert statt vom CDN.
WebP-Bilder
Fotos von rund 2 MB auf rund 400 KB je Bild gebracht – etwa 80 Prozent kleiner bei gleicher Optik.
Eigener Consent-Tracker
Shop-Funnel und Leads messen, DSGVO-konform und ohne Google Analytics.
Antippen zeigt, warum ich mich dafür entschieden habe.
SEO
5
- Meta-Title und Description mit Ort, Angebot und Aufforderung („Jetzt bestellen“)
- JSON-LD vom Typ Restaurant mit Adresse, Geokoordinaten und Öffnungszeiten
- Sitemap und robots.txt vorhanden, OG-Bild für Messenger und Social Media
- Bewusst noindex: Es ist ein fiktiver Betrieb – er soll bei Google nicht mit echten Pizzerien konkurrieren. Vor einem echten Live-Gang wird das entfernt.
- Saubere Überschriften-Hierarchie und sprechende Sektions-IDs für Ankerlinks
Barrierefreiheit
5
- Kontraste nach WCAG geprüft und Farbtöne für Text auf Creme angepasst
- Alle Touch-Ziele mindestens 44 Pixel, Eingabefelder 16 Pixel (kein Zoom-Sprung auf iOS)
- Skip-Link zum Inhalt; Dialoge (Warenkorb, Kasse, Bestätigung) setzen inert und aria-hidden auf den Hintergrund
- Emojis durch Inline-SVG ersetzt, damit Screenreader nichts Sinnloses vorlesen
- Animationen respektieren prefers-reduced-motion
Datenschutz
5
- Schriften und GSAP self-hosted – keine Verbindung zu Google Fonts oder CDNs
- Google Maps nur per Zwei-Klick: die Karte lädt erst nach aktiver Zustimmung
- Consent-Dialog im Markenlook; Messung erst nach Einwilligung
- Kartendaten bleiben bei Stripe – die Website sieht keine Kartennummern
- Bestelldaten verfallen nach 14 Tagen automatisch; Kontaktformular geht per Worker an Telegram, nicht an Formspree
Performance
Gemessen am 16. September 2026, mobil (simulierte 4G-Drosselung) mit Lighthouse.
- Bildgewicht
- ~2 MB → ~400 KB je FotoWebP, etwa 80 Prozent kleiner
- Fonts
- self-hosted, 0 externe Requests8 WOFF2-Dateien
- Animation
- GSAP lokal statt vom CDNkeine Drittserver-Abhängigkeit
- Backend
- Cloudflare-Edgekein eigener Server, kein Kaltstart
Der Lighthouse-SEO-Wert ist hier bewusst reduziert: Die Seite trägt „noindex", weil sie als Konzept bzw. privates Projekt nicht in Suchmaschinen erscheinen soll. Alle übrigen SEO-Prüfungen bestehen.
Der Performance-Wert liegt unter meinem Ziel von 80. Die Messung ist echt und bleibt hier stehen, bis die Optimierung (Bildgrößen, Ladereihenfolge) umgesetzt und neu gemessen ist.
Ablauf
6 Schritte von der Idee bis online
Analyse des Bundles
Das exportierte Baukasten-Bundle war nicht editierbar. Entscheidung: Neuaufbau in sauberem HTML/CSS/JS.
Seite neu bauen
Struktur, Speisekarte und Warenkorb im Frontend; Fotos zu WebP, Fonts und GSAP lokal eingebunden.
Backend auf Cloudflare
Worker mit Menü als Preiswahrheit, KV-Speicher, Öffnungszeiten-Logik und Origin-Härtung.
Stripe anbinden
Checkout-Session, Webhook mit Signaturprüfung, Bezahlt-Screen mit Bestellnummer.
WinOrder + Telegram
Bezahlte Bestellung als Kassen-Datensatz ablegen und den Betrieb sofort benachrichtigen.
Audit und Test
WCAG-Kontraste, Touch-Ziele, Dialog-Fokus; komplette Bestellkette mit Testkarte durchgespielt.
Ergebnis
Was am Ende belegbar dasteht
- Kette Zahlung → Webhook → WinOrder-Datensatz → Telegram mit Stripe-Testkarte erfolgreich durchgetestet
- Bildgewicht um rund 80 Prozent reduziert (WebP)
- Keine externen Requests für Fonts oder Animationen; Maps nur nach Klick
- Shop-Funnel wird im eigenen Analytics-Dashboard als eigenes Panel ausgewertet
- Für den Echtbetrieb fehlen nur noch Live-Keys, echte Artikelnummern und der WinOrder-Zustellweg
Learnings
Was ich mitnehme
Preise gehören auf den Server. Sobald der Browser rechnet, ist jede Bestellung manipulierbar.
Der Webhook kommt manchmal später an als der Gast zurück auf der Seite ist – der Tracker braucht eine kurze Warteschleife statt einer Fehlermeldung.
Öffnungszeiten müssen an zwei Stellen gepflegt werden (Frontend und Server). Das ist ein Wartungsrisiko, das ich beim nächsten System zentralisiere.
Ein Baukasten-Export ist keine Basis. Neu bauen war schneller als reparieren.
Fragen zum Projekt
Häufige Fragen
Kann ich so ein Bestellsystem für mein Restaurant bekommen?
Ja. Der Aufbau ist übertragbar: Website mit Speisekarte und Warenkorb, Zahlung über Stripe, Benachrichtigung per Telegram oder E-Mail. Die Details besprechen wir persönlich – siehe Online-Bestellsystem.
Fallen laufende Kosten für das Bestellsystem an?
Das Backend läuft auf Cloudflare im kostenlosen Tarif. Stripe berechnet pro Zahlung eine Transaktionsgebühr, aber keine Provision auf den Bestellwert wie Lieferplattformen.
Funktioniert das auch mit einer anderen Kasse als WinOrder?
Die Bestellung liegt als strukturierter Datensatz vor. Die Übergabe lässt sich an jedes Kassensystem anpassen, das Bestellungen per E-Mail, API oder Datei entgegennimmt.
Ist Pizza Blitz ein echter Kunde?
Nein. Pizza Blitz ist ein fiktiver Betrieb, den ich als Prototyp gebaut habe. Die Zahlung läuft im Stripe-Testmodus – es wird nichts wirklich abgebucht.
Passende Leistungen
Das steckt dahinter
Ähnliches Projekt?
Sie brauchen so etwas für Ihren Betrieb?
Schreiben Sie mir, was Sie vorhaben. Ich sage Ihnen ehrlich, was sinnvoll ist, und nenne einen Festpreis.