Jak zbudowaliśmy Mirai Gastro w 2 tygodnie

Dwa tygodnie od pomysłu do działającego SaaS-u dla restauracji. Bez zespołu, bez inwestora, z AI jako trzecim członkiem zespołu. Pokazujemy stack, decyzje i to, co zajęło więcej czasu niż myśleliśmy.

Dwa lata temu zbudowanie SaaS-u w dwa tygodnie brzmiało jak żart. Dziś — to realne. I dziś chcemy Wam pokazać, jak to zrobiliśmy.

Mirai Gastro to nasz pierwszy własny produkt. System dla restauracji, który liczy zapotrzebowanie i generuje gotowe zamówienia do dostawców. Zamiast awaryjnych wypraw do Biedronki w sobotę o 14:00.

Jest live. Możecie go otworzyć i sami sprawdzić.

Ten artykuł to kulisy budowania. Co użyliśmy, co działało, co zajęło więcej czasu niż się spodziewaliśmy.

Stack — co użyliśmy

Cztery rzeczy, każda robi co innego:

n8n — serce automatyzacji. Wszystkie workflow-y które nie są UI: czytanie zamówień historycznych, liczenie prognoz, wysyłka maili, integracje z dostawcami. To jest miejsce, gdzie żyje większość logiki produktu. Nie pisaliśmy własnego backendu — n8n robi rzeczy szybciej niż Express.

Next.js — frontend. Cały panel restauratora, formularze, wykresy zapotrzebowania, login. Klasyczny App Router, Tailwind, Vercel jako hosting.

Gemini, OpenAI i Claude — trzy modele AI, każdy do innych zadań. Gemini do prognozowania zapotrzebowania na bazie sezonu i historii. OpenAI do generowania komunikatów dla dostawców („dzień dobry, prosimy o..."). Claude do najtrudniejszych decyzji — kiedy historia danych jest niejednoznaczna i potrzeba długiego rozumowania. Każdy model do swojego zadania, zamiast jednego do wszystkiego.

Google Workspace — przechowywanie danych restauracji. Sheets jako baza dla restauratorów którzy chcą widzieć swoje liczby (a w gastronomii prawie każdy preferuje arkusz nad bazę danych). Drive na faktury i dokumenty. Gmail jako kanał komunikacji z dostawcami.

Czego specjalnie nie użyliśmy:

• Własnego backendu (Express, NestJS, FastAPI). n8n + Supabase wystarczyło.
• Frameworka mobilnego. Restauratorzy operują głównie na laptopach i tabletach, mobile to drugorzędny use case.
• Płatności na start. Mirai Gastro jest na etapie pilotażu — pierwsi klienci dostają preferencyjne warunki, a Stripe podepniemy gdy będzie kogo billować.

Dwa tygodnie — co się zmieściło

Pierwszy tydzień: szkielet. Drugi tydzień: szlif.

Dni 1-3: Zaprojektowaliśmy flow użytkownika na kartce. Restaurator loguje się, wpisuje swoje pozycje menu, system zaciąga historię sprzedaży, generuje prognozę na następny tydzień, pokazuje listę zakupów per dostawca. To wszystko.

Postawiliśmy frontend w Next.js, autentykację, podstawowe widoki. Bez logiki, bez stylowania.

Dni 4-7: Backend w n8n. Workflow do liczenia zapotrzebowania. Pierwsze podpięcie z modelami AI. Obsługa różnych typów dań (te z dłuższym łańcuchem składników, te które trzeba przygotować dzień wcześniej, te sezonowe).

Pierwsza wersja działała. Wyglądała brzydko. Mówiła w surowym języku programisty. Ale działała.

Dni 8-12: Najtrudniejszy moment. Wzięliśmy produkt do realnego restauratora i pokazaliśmy. Zrozumieliśmy, że programista i restaurator to dwa różne gatunki ludzi.

Dni 13-14: Dopinanie maili dla dostawców, integracja z Calendly do umawiania spotkań z naszym supportem, pierwsza wersja onboardingu. Deploy.

Co zajęło więcej czasu niż myśleliśmy

Nie technologia. UX dla restauratora.

Programiści mają tendencję do projektowania dla siebie. „No co tam, kliknie w panel, doda dostawcę, ustawi limity." A restaurator ma 14h pracy dziennie, sumiarcze paznokcie od cebuli i nie ma cierpliwości do form z 20 polami.

To, co zajęło nam ponad połowę czasu, to nie kod. To redukcja kliknięć i pól. Wycinanie wszystkiego, co nie jest absolutnie konieczne.

Konkretne decyzje, które zmieniliśmy w trakcie:

• Onboarding bez wpisywania menu. W pierwszej wersji restaurator miał wbić swoje pozycje menu ręcznie. Po pierwszej rozmowie z prawdziwym właścicielem zrozumieliśmy, że nikt tego nie zrobi. Zamiast tego — wrzucasz zdjęcie menu, AI je czyta i wstępnie kategoryzuje. Zatwierdzasz albo poprawiasz.
• Lista zakupów jako mail, nie panel. W pierwszej wersji restaurator miał logować się żeby zobaczyć listę. W drugiej — system sam wysyła mail z gotową listą, w piątek o 8:00. Można skopiować i wysłać do dostawcy w 30 sekund. Albo włączyć auto-wysyłkę i nawet tego nie robić.
• Surowy język AI. „System zidentyfikował zwiększone zapotrzebowanie na karkówkę w segmentach weekendowych" — komunikat tylko na pokaz. Zmieniliśmy na: „W ten weekend prawdopodobnie sprzedasz więcej karkówki niż zwykle. Polecamy zwiększyć zamówienie o 15%." Krótko, po polsku, bez slangu IT.

Każda z tych decyzji wymagała kilkunastu poprawek. Razem zajęły więcej czasu niż cały backend.

Co byśmy zrobili inaczej

Zaczęlibyśmy od rozmowy z restauratorem, nie od kodu.

Tracenie 5 dni na backend, który potem trzeba dostosować do realnych wymagań klienta, jest tragedią.

Następne produkty Mirai Lab będą zaczynać się od dwugodzinnej rozmowy z 3-5 osobami z target grupy. Dopiero potem klawiatura.

Wnioski dla Ciebie

Jeśli czytasz to jako właściciel firmy, który myśli o własnym produkcie SaaS — kilka rzeczy z naszej strony:

• Stack nie jest problemem. Next.js + n8n + AI = możesz zbudować większość rzeczy w tydzień. Technologia od dwóch lat jest tak dobra, że wąskim gardłem jest wszystko inne.
• MVP to nie znaczy „brzydki". Znaczy „realnie używalny". Restaurator, który nie zrozumie panelu w 2 minuty, nie wróci.
• AI nie jest produktem. AI jest składnikiem. Mirai Gastro nie jest „SaaS-em z AI". Jest narzędziem do zarządzania zapotrzebowaniem, w którym AI gdzieniegdzie pomaga. Klient nie kupuje AI. Klient kupuje to, że nie biega w sobotę po Biedronce.

Jeśli macie pomysł na produkt i chcecie go zbudować — napiszcie. Albo zbudujemy razem, albo polecimy kierunek.

A jeśli macie restaurację — Mirai Gastro jest live. Pierwszy miesiąc preferencyjnie, w zamian za feedback. Czekamy.