3Smiles ist in Produktion. Die Website läuft unter 3smiles.eu, das Backoffice für den Gastronomen unter app.3smiles.eu, und die Azure-Infrastruktur arbeitet mit echten Abonnements, echten Transaktions-E-Mails und echten Restaurantdaten. Es ist die erste Geschäftsanwendung von FlorisNexus, die keine Schaufenster-Website ist — und ein guter Anlass, ehrlich zu beschreiben, was ein solches Projekt verlangt.
Das Problem: eine triviale Bitte kostet einen Weg durch den Raum
Im Restaurant sind die meisten Gastwünsche winzig: die Rechnung, eine Karaffe Wasser, ein fehlendes Besteck. Der Aufwand liegt nicht in der Ausführung — er liegt in der Übermittlung. Ein Gast hebt die Hand, sucht Blickkontakt, wartet. Eine Servicekraft durchquert den Raum, nur um den Wunsch zu hören, und durchquert ihn ein zweites Mal, um ihn zu erfüllen.
Der Ausgangspunkt des Projekts war also: es fehlt ein direkter Kanal zwischen Tisch und Team. Mit drei nicht verhandelbaren Bedingungen. Keine Hardware zu installieren — der Knopfkasten auf jedem Tisch ist die Antwort eines Wettbewerbers, nicht unsere. Nichts zum Herunterladen für den Gast — ein Restaurant kann einem Paar in den Dreißigern nicht zumuten, eine App zu installieren, um Wasser zu bestellen. Und vor allem: den menschlichen Kontakt nicht ersetzen, sondern ihm nur die unnötigen Wege ersparen.
Was 3Smiles konkret tut
Jeder Tisch trägt einen QR-Code. Der Gast scannt ihn mit der Kamera seines Telefons — keine Installation, kein Konto, kein Passwort — und landet auf einem Bildschirm mit den Services, die dieses Restaurant anbietet. Er wählt einen aus. Die für diesen Bereich zuständige Servicekraft erhält die Anfrage sofort, auf Tablet oder Telefon, mit der Tischnummer.
Es ist keine digitale Speisekarte, und es werden keine Gerichte bestellt: das Produkt löst den Rufkanal, nicht die Bestellaufnahme. Dahinter erhält der Gastronom ein vollständiges Backoffice: seine Betriebe, seine Bereiche (Terrasse, Saal, Obergeschoss), seine Tische, die Liste der Services, die er anbieten möchte, seine Teammitglieder und sein Abonnement. Alles in drei Sprachen — Französisch, Englisch und Niederländisch — denn ein belgisches Restaurant bedient alle drei am selben Abend.
Warum das keine Schaufenster-Website war
Wir haben einen Leitfaden veröffentlicht, der Schaufenster-Website und Geschäftsanwendung vergleicht. 3Smiles ist das Musterbeispiel für den zweiten Fall, und die Grenze zeigt sich an vier Anzeichen.
Es gibt einen Zustand zu verwalten. Eine Serviceanfrage entsteht, wird übernommen, abgeschlossen oder storniert. Eine Gastsitzung beginnt beim Scannen und endet später. Eine Schaufenster-Website erinnert sich an nichts.
Es gibt Echtzeit. Eine Benachrichtigung, die dreißig Sekunden zu spät kommt, ist wertlos: der Gast hat längst die Hand gehoben.
Es stecken mehrere Kunden in einem Produkt. Jedes Restaurant ist ein Mandant, der niemals die Daten eines anderen sehen darf.
Es geht um Geld. Ein monatliches oder jährliches Abonnement, fehlgeschlagene Zahlungen, Rechnungen, Mehrwertsteuer.
Jeder dieser vier Punkte vervielfacht die Arbeit gegenüber einer Schaufenster-Website. Deshalb ist die Frage „Website oder Anwendung?" kein Wortspiel: sie verändert Budget, Zeitplan und das, was über Jahre gepflegt werden muss.
Die technischen Entscheidungen — und was jede schützt
3Smiles läuft auf .NET 10, mit Gastoberfläche und Backoffice in Blazor WebAssembly, Echtzeit über SignalR, einer einzigen Azure SQL-Datenbank und einer vollständig in Bicep beschriebenen Azure-Infrastruktur. Nichts davon ist Mode; jede Entscheidung schützt etwas Konkretes.
SignalR statt periodischer Aktualisierung: die Anfrage erreicht den Servicebildschirm in wenigen Sekunden, ohne dass die App den Server sinnlos abfragt.
Eine Datenbank, isoliert über eine Mandantenkennung statt einer Datenbank pro Restaurant: die Isolationsfilter greifen global auf der Datenzugriffsschicht, wodurch „das Filtern vergessen" wirklich schwer wird — und wir einmal für alle Kunden ausrollen.
Microsoft Entra External ID für die Identität: keine von uns gespeicherten Passwörter oder Tokens, MFA verfügbar, und eine Angriffsfläche, die an Microsoft delegiert statt selbst nachgebaut ist.
Stripe für das Abonnement: es gehen niemals Kartendaten durch die Anwendung.
Bicep für die Infrastruktur: die Produktionsumgebung steht in einer versionierten Datei, mit einer davon getrennten Testumgebung daneben. Genau das macht es möglich, eine Infrastrukturänderung zu testen, ohne an einem Restaurant im laufenden Service zu experimentieren.
Zuerst Belgien, dann Europa
3Smiles startet auf dem belgischen Markt: dort stehen die ersten Restaurants, und das ist der Markt, den der Projektinhaber kennt. Halt machen soll das Produkt dort aber nicht — und das ist bereits in die Architektur eingebaut. Eine einzige mandantenfähige Instanz bedient alle Kunden, ein weiteres Land bedeutet also kein weiteres Deployment. Die Oberfläche ist von Tag eins dreisprachig, weil Mehrsprachigkeit nachträglich einzubauen die teuerste Variante ist. Stripe rechnet in über 40 Ländern ab. Und weil die Infrastruktur in Bicep beschrieben ist, lässt sie sich in einer anderen Azure-Region erneut ausrollen, ohne neu geschrieben zu werden.
Die Reihenfolge ist bewusst gewählt: erst das Produkt in einem belgischen Gastraum beweisen, dann nach Europa erweitern — und warum nicht weiter. Produkte, die vom ersten Tag an die ganze Welt ansprechen wollen, überzeugen meist niemanden im Besonderen.
Was der Gastraum am Produkt verändert hat
Der lehrreichste Teil des Projekts ist nicht die Architektur — es ist die Liste der Dinge, die keine Spezifikation vorhergesehen hatte.
Die Reihenfolge der Bereiche. Die Bereichsliste war alphabetisch sortiert. Folge: ein Gastronom, dessen Hauptsaal „Terrasse" heißt, sah ihn immer in der letzten Spalte des Servicebildschirms, ohne jede Möglichkeit, ihn nach vorn zu holen. Eine vom Gastronomen selbst bestimmte Reihenfolge musste her.
Pfeile, kein Drag-and-drop. Zum Umsortieren dieser Liste ist Drag-and-drop der Entwicklerreflex. Schlechte Idee: die zugehörigen Events feuern bei Berührung in den meisten mobilen Browsern nicht, und dieses Backoffice wird stehend auf einem Tablet im Gastraum benutzt. Zwei Pfeile erledigen die Aufgabe und funktionieren überall.
Das erneute Scannen des QR-Codes. Ein Gast scannt den Code mitten im Essen erneut, oder sein Tischnachbar scannt denselben Tisch. Der Lebenszyklus von Sitzungen und Anfragen brauchte mehrere Durchgänge, bis er in all diesen Fällen stimmte.
Die abgelehnte Zahlung. Eine ablaufende Karte darf den Service eines Restaurants nicht mitten am Abend abschneiden: in die Abrechnung kam eine Kulanzfrist. Die richtige technische Antwort auf eine fehlgeschlagene Zahlung ist selten „sofort sperren".
In Produktion gehen ist nicht dasselbe wie ausrollen
Das ist die Lehre, die von diesem Projekt am meisten bleibt. Der Code funktionierte längst, als der Produktionsstart begann. Was diese Phase wirklich ausfüllte, war für Nutzer unsichtbar:
Eine eigene Absenderdomäne. Die Einladungen gingen von einer automatisch generierten Azure-Adresse aus — genau die Art Absender, die ein Gastronom ungeöffnet als Spam einordnet. Der Wechsel auf eine Adresse der Kundendomäne verlangte eine eigene Subdomain und saubere DNS-Einträge zur E-Mail-Authentifizierung, um das bestehende Geschäftspostfach nicht zu beschädigen.
Das Backoffice von Suchmaschinen ausgeschlossen. Die Anwendung hatte weder eine robots.txt noch einen entsprechenden Header — und das Fehlen dieser Datei erlaubt das Crawlen, statt es zu verbieten.
Sicherheitsheader, die tatsächlich ausgeliefert werden. Die der Schaufenster-Website waren korrekt geschrieben, wurden in Produktion aber nie ausgeliefert, weil die Konfigurationsdatei nicht im veröffentlichten Ordner lag. Geschrieben ≠ ausgerollt: man muss es an der Produktions-URL prüfen.
Dimensionierung und Migrationen. Die Produktion auf den richtigen Hosting-Tarif bringen und sicherstellen, dass eine Datenbankmigration nicht vorzeitig auf die Produktion angewendet werden kann.
Die rechtliche Grundlage. Nutzungsbedingungen, Datenschutzerklärung, Impressum und Auftragsverarbeitungsvertrag in drei Sprachen, mit einer beim ersten Login des Managers zeitgestempelt und versioniert gespeicherten Zustimmung. Bei einem Produkt, das Daten im Auftrag anderer Unternehmen verarbeitet, ist das keine Formalität zum Projektende.
Nichts davon taucht in einer Demo auf. Alles davon blockiert einen echten Start. Wenn ein Anbieter Ihnen sagt, eine Geschäftsanwendung sei „fertig", ohne diese Themen besprochen zu haben, ist sie es nicht.
Was wir messen und was wir noch nicht haben
Die 3Smiles-Website wird wie alle unsere Projekte in Produktion mit Lighthouse gemessen: 97 Performance, 97 Barrierefreiheit, 100 Best Practices und 100 SEO am Desktop; 86, 96, 100 und 100 auf dem Smartphone (Median aus drei Durchläufen, 10. August 2026). Wir veröffentlichen diese Zahlen unbearbeitet, auch wenn sie nicht schmeicheln, auf unserer Seite Referenzen.
Was wir heute nicht veröffentlichen, sind Nutzungszahlen: eingesparte Wartezeit, bearbeitete Anfragen pro Service, Gästezufriedenheit. Das Produkt ist gerade erst in Produktion gegangen. Diese Messwerte gibt es, wenn sie über mehrere Wochen im Gastraum beobachtet wurden — nicht vorher. Eine erfundene oder hochgerechnete Zahl ist genau das Detail, das den Rest einer Fallstudie unglaubwürdig macht.
Was dieses Projekt über Ihres sagt
Wenn Sie selbstständig sind, ein Geschäft führen oder ein KMU in Belgien leiten und eine konkrete Reibung in Ihrem Alltag erkannt haben — ein Anruf, der nie die richtige Person erreicht, Informationen, die dreimal abgetippt werden, ein Dienstplan auf Papier — dann gelten drei Lehren aus diesem Projekt auch für Ihres.
Beginnen Sie bei der Reibung, nicht bei der Funktion. 3Smiles kann nicht „alles, was ein Restaurant wollen könnte". Es streicht einen Hin- und Rückweg. Ein schmaler, wirklich nützlicher Umfang wird geliefert; eine Wunschliste nie.
Der Gastraum gewinnt immer gegen das Mockup. Die wichtigsten Korrekturen dieses Projekts kamen von einem Tablet in der Hand in einem Speisesaal, nicht aus einer Besprechung.
Planen Sie die unsichtbare Phase ein. Domänen, E-Mail, Sicherheit, DSGVO, Abrechnung: nehmen Sie sie von Anfang an in den Zeitplan, sonst verschiebt sie Ihren Start um Wochen.
Und ein letzter Punkt, bei dem FlorisNexus keine Kompromisse macht: Infrastruktur und Konten bleiben auf den Namen des Kunden. Das Azure-Abonnement von 3Smiles gehört dem Projektinhaber, nicht uns. Sie müssen den Anbieter wechseln können, ohne das Produkt zu wechseln.