Rozwiązania · Restauracje i HoReCa
Menu lokalu to nie broszura: ma ceny i pojemności, które muszą być dokładne, często się zmienia i jest czytane przez osoby mówiące trzema językami. Budujemy menu jako dane, generujemy stronę z nich i sprawdzamy przed każdą publikacją, w tym czy ceny schodzą w każdej kategorii i czy każde zdjęcie istnieje.
Już zbudowaneDwa cyfrowe menu w produkcji, możliwe do sprawdzenia z zewnątrz dziś. Pierwsze: 119 produktów w 21 kategoriach, z ceną, objętością, składem i fotografią, plus krótki tekst prezentacyjny i zestaw rekomendacji łączenia dla każdego produktu; generator ma 402 linie, a kontrola przed publikacją ma 233 linie i 16 bloków. Drugie, siostrzana strona z tym samym silnikiem: 146 produktów w 31 kategoriach, generator 377 linii, kontrola 210 linii z 14 blokami, a ciągła integracja regeneruje stronę ze źródeł i odrzuca zmianę, jeśli wynik różni się od pliku w repozytorium. Oba odpowiadają 200 i żadne nie ustawia żadnego cookie — sprawdzone przeze mnie 06.09.2026. Mówimy też, że są to dwa utwory z tym samym silnikiem i tym samym właścicielem, a nie dwa niezależne utwory.
Zeskanowany PDF pod kodem QR nie rozwiązuje niczego, co lokal ma do rozwiązania. Nie da się w nim szukać, nie tłumaczy się go, nie powiększa się go dobrze na telefonie i nie da się go zmienić bez ponownego drukowania kodu. A menu zmienia się często: kuchnia usuwa danie, bar dostaje nową markę, cena pozycji rośnie. Menu to zestaw danych zmieniający się co tydzień, a nie dokument wydrukowany raz.
Dlatego traktujemy je jako dane. Rzeczywiste źródła to kilka uporządkowanych plików — produkty, teksty prezentacyjne, rekomendacje łączenia, tłumaczenia — a generator napisany w Pythonie składa z nich jedną stronę. W jednym z lokali: 119 produktów w 21 kategoriach, każdy z ceną, pojemnością, składem i zdjęciem, plus 119 krótkich tekstów i 119 zestawów „z czym pasuje”. W drugim: 146 produktów w 31 kategoriach. Strony nie edytuje się bezpośrednio — jest regenerowana.
Tłumaczenie nie kończy się na przyciskach. Rumuński jest bazą, a rosyjski i angielski obejmują kategorie, nazwy, pojemności, składy, 82 etykiety smaku i wszystkie teksty prezentacyjne. W mieście, w którym sąsiedni stolik zamawia w innym języku, menu przetłumaczone w połowie jest bardziej irytujące niż nietłumaczone: daje do zrozumienia, że można przeczytać wszystko.
Część, którą uważamy za najważniejszą i o którą nikt nie prosi w briefie: koszyk, lista ulubionych i dzielenie rachunku działają w przeglądarce, bez konta i bez serwera, a strona nie ustawia żadnego cookie i nie żąda niczego z domeny trzeciej. To nie jest obietnica z polityki prywatności — to reguła narzucona przez automatyczne kontrole uruchamiane przed każdą publikacją, które odrzucają zmianę, jeśli pojawił się jakikolwiek tracker, jakikolwiek zasób zewnętrzny albo jakikolwiek font pobrany od kogoś innego.
Co obejmuje
Produkty, teksty prezentacyjne, rekomendacje i tłumaczenia są zapisane w uporządkowanych plikach; generator napisany w Pythonie — 402 linie w jednym lokalu, 377 w drugim — składa z nich jedną stronę. Opublikowanej strony nie edytuje się ręcznie; gdy ktoś to robi, ciągła integracja to wychwytuje, bo regeneruje stronę i porównuje wynik.
W barze objętość jest częścią ceny: ta sama nazwa przy 40 i przy 100 mililitrach to dwa różne produkty, a klient, który nie widzi objętości, myśli, że powiedziano mu coś innego. Struktura danych traktuje wszystkie cztery pola jako obowiązkowe, a nie opcjonalne, właśnie po to, by niepełna pozycja nie trafiła na stół.
Tłumaczenie obejmuje interfejs, kategorie, nazwy, objętości, składy, wszystkie 82 etykiety smaku i wszystkie krótkie teksty prezentacyjne, a każda rumuńska klucz ma swoją parę po rosyjsku i angielsku. Jedna z kontroli przed publikacją nie przechodzi, jeśli menu nie jest kompletne we wszystkich trzech językach.
Bez konta, bez serwera, bez wysyłania danych gdziekolwiek. Klient komponuje zamówienie na telefonie i pokazuje je osobie obsługującej albo używa go do podziału rachunku. Konsekwencja techniczna: nie istnieje baza z tym, co zamówiły Twoje klientki i klienci, bo żadna nie jest tworzona.
Sprawdzone z zewnątrz: brak nagłówka cookie na żadnej z dwóch stron, a polityka treści jednej z nich nie dopuszcza absolutnie niczego z zewnątrz. Fonty są hostowane na tej samej domenie, nie u zewnętrznego serwisu. Jedynymi zewnętrznymi adresami na stronie są linki do profili lokalu w mediach społecznościowych — które odwiedzający otwiera, a nie strona.
Szesnaście bloków kontroli w jednym lokalu, czternaście w drugim: bez trackerów, bez zasobów ładowanych automatycznie od stron trzecich, fonty hostowane samodzielnie, poprawne pliki strukturalne, każde zdjęcie istnieje, menu kompletne w trzech językach, dane strukturalne na stronie poprawne i — to, co zaskakuje wszystkich — ceny idą w dół w każdej kategorii. Błędnie wpisana cena widać jako nieciągłość w kolejności listy, a nie przy reklamacji klienta.
Przy każdej zmianie ciągła integracja generuje stronę na nowo ze źródeł i odrzuca zmianę, jeśli wynik różni się od pliku w repozytorium. To jedyna realna gwarancja, że to, co jest na ekranie klienta, pochodzi z danych edytowanych lokalnie przez lokal, a nie z ręcznej ingerencji zapomnianej tam trzy miesiące temu.
W konfiguracji serwera jednego z lokali: maskowanie adresów IP, usunięte z logu nagłówki identyfikacyjne i ograniczony okres przechowywania, z wyraźnym odniesieniem do zasady ograniczenia przechowywania. Ciągła integracja odrzuca zmianę, jeśli z konfiguracji znikną te linie — więc ochrona nie może po cichu zniknąć przy zmianie serwera.
Nie przekazuje zamówienia do kuchni i nie potwierdza rezerwacji: do tego potrzebne jest połączenie z systemem operacyjnym lokalu, a to osobna praca. I nie publikujemy funkcji, które obiecują coś, co trzeba zrealizować przy kasie — zniżka typu „happy hour” albo harmonogram kuchni nie uruchamia się bez pisemnej zgody lokalu, bo za obietnicę na ekranie płaci osoba przy ladzie.
Traseul
Pierwszym etapem dostawy jest menu jako dane: kategorie, pozycje, cena, objętość, skład, fotografia. Tu wychodzą też braki — pozycje bez objętości, kategorie, które w rzeczywistości są dwiema, produkty bez fotografii. Cyfrowe menu zbudowane na niepełnych danych wygląda na niepełne, niezależnie od tego, jak dobry jest projekt.
Kategorie, nazwy, ilości, składy, etykiety smaków i teksty prezentacyjne otrzymują swoje odpowiedniki po rosyjsku i angielsku. Dostarczamy pełne menu w trzech językach oraz automatyczną weryfikację, która nie przechodzi, jeśli choć jeden klucz pozostaje nieprzetłumaczony.
Bez śledzących, bez zasobów od osób trzecich, czcionki hostowane samodzielnie, poprawne pliki, każde zdjęcie obecne, ceny w kolejności malejącej w każdej kategorii, poprawne dane strukturalne. Dostarczamy skrypt weryfikacyjny do repozytorium, aby lokal mógł uruchamiać go także bez nas.
Publikacja następuje przy scaleniu zmian, po tym jak integracja ciągła wygenerowała ponownie stronę i porównała ją ze źródłami, oraz po zachowaniu kopii wersji sprzed zmian. Dostarczamy dostęp i procedurę powrotu — nie tylko uruchomioną stronę.
Dane
Zasady różnią się w zależności od branży. To są te, które obowiązują w restauracjach i horeca.
Przykład
Sytuacja
W menu z ponad setką pozycji najczęstszy błąd nie dotyczy projektu, tylko wpisywania: jedna cyfra za dużo w cenie albo pozycja bez zdjęcia. Oba zwykle wychodzą na jaw dopiero wtedy, gdy klient pokazuje je kelnerowi.
Co zbudowaliśmy
Przed publikacją włączyliśmy skrypt sprawdzający — 233 linie w jednym lokalu, 210 w drugim — który uruchamia odpowiednio szesnaście i czternaście bloków: czy nie wkradł się żaden tracker, czy strona niczego nie żąda z domeny zewnętrznej, czy czcionki są hostowane lokalnie, czy pliki danych są poprawne i czy każde zdjęcie istnieje, czy menu jest kompletne we wszystkich trzech językach, czy dane strukturalne na stronie są poprawne oraz czy ceny spadają w każdej kategorii. Dodatkowo ciągła integracja odtwarza stronę ze źródeł przy każdej zmianie i odrzuca ją, jeśli wynik różni się od opublikowanego pliku.
Co z tego wyszło
Błąd wpisania ceny psuje kolejność malejącą i zatrzymuje publikację, a brakujące zdjęcie nigdy nie trafia na ekran przy stoliku. Opublikowana strona zawsze odpowiada danym edytowanym przez lokal, bo w przeciwnym razie nie jest publikowana.
Czego nie mówi ten przypadek
Kontrole wyłapują to, co da się sprawdzić mechanicznie. Źle wpisana, ale wiarygodna — i nadal w kolejności — cena przejdzie; dla niej nie ma innego mechanizmu niż czyjś wzrok. Dokumentacja jednego z projektów podaje „14 kontroli” tam, gdzie skrypt ma 16 bloków; poprawna liczba jest ta ze skryptu.
Pytania
Tak. Edytuje się dane, nie stronę; strona jest z nich odtwarzana. Ciągła integracja sprawdza odtworzenie przy każdej zmianie i odrzuca zmianę, jeśli opublikowana strona nie odpowiada już źródłom. Dzięki temu nie ma scenariusza, w którym ktoś poprawił cenę bezpośrednio na stronie, a zmiana zniknęła przy następnej publikacji.
Bo menu, które niczego nie zbiera, nie potrzebuje paska zgody, nie ma czego wyciekać i nie ma nic do wyjaśnienia kontrolującej osobie. Sprawdzenie jest dostępne dla każdego: jedno żądanie do strony pokazuje, że nie zwraca się żaden nagłówek cookie. A polityka treści jednego z lokali nie dopuszcza absolutnie żadnego zasobu z zewnątrz.
Koszyk działa w przeglądarce, jako lista, którą klient pokazuje kelnerowi albo używa do podziału rachunku. Przesłanie zamówienia do kuchni wymaga połączenia z systemem lokalu i jest osobnym zadaniem, z wcześniejszym sprawdzeniem zgodności. Nie nazywamy „zamówieniem online” koszyka, który nigdzie nie trafia.
Da się to zbudować, ale nie uruchamiamy tego bez pisemnej zgody lokalu, bo to obietnica realizowana przy kasie. Nasza zasada: funkcje zobowiązujące lokal wobec klienta — rabaty, godziny kuchni, dostępność — nie są publikowane na podstawie rozmowy ustnej.
Trzy: rumuński jako baza, rosyjski i angielski. Kompletnie oznacza kategorie, nazwy, objętości, składy, etykiety smaku oraz teksty prezentacyjne, a nie tylko przyciski. Automatyczna kontrola pada, jeśli menu nie jest kompletne we wszystkich trzech — dlatego nie trafia na stronę w połowie przetłumaczone.
Wśród kontroli przed publikacją jest taka, która wymaga, by ceny spadały w każdej kategorii. To nie jest reguła handlowa, tylko wykrywacz błędów wpisywania: pozycja wprowadzona z jedną cyfrą za dużo albo za mało łamie kolejność i zatrzymuje publikację. Pozostałe kontrole zajmują się brakującymi zdjęciami i nieprawidłowymi plikami.
Rezultatem jest jedna wygenerowana strona, z czcionkami hostowanymi na tej samej domenie i bez zasobów pobieranych z domen zewnętrznych. To oznacza mniej połączeń do otwarcia i nic, co miałoby czekać na zewnętrzną usługę. Nie publikujemy liczb szybkości zmierzonych w innych warunkach niż Twoje.
Tak, i wtedy polityka treści strony dopuszcza dokładnie tę domenę, nic więcej. W jednym z dwóch lokali widać to z zewnątrz. Warto powiedzieć też odwrotną stronę: w tym momencie strona nie jest już „bez niczego z zewnątrz”, więc decyzję podejmuje się świadomie, nie jako bonus.
To są dwie strony z tym samym silnikiem, tego samego właściciela, i mówimy to wprost. Zadeklarowaną różnicą funkcjonalną między nimi są rekomendacje łączenia per produkt, których druga nie ma. Moglibyśmy przedstawić je jako niezależne realizacje; byłoby to jednak zawyżenie portfolio.
Opowiedz nam o swoim procesie. Wspólnie ustalimy, co warto zbudować, co da się połączyć i jak sprawdzimy wynik.