WTFridge — Projekt własny

Większość ludzi wyrzuca jedzenie nie dlatego, że nie umie gotować. Wyrzuca, bo nie wie, co z tego ugotować. Trzy składniki, które do siebie nie pasują, kończą w koszu — a razem z nimi pieniądze. WTFridge rozwiązuje dokładnie ten problem: wpisujesz, co masz w domu, a aplikacja generuje przepis dopasowany do twojego sprzętu, diety, czasu i poziomu głodu.

To nie jest kolejne demo z jednym polem tekstowym. To kompletny produkt, który zaprojektowałem i zbudowałem od zera — od pomysłu i UX, przez własny design system, po warstwę serwerową i inżynierię promptów. Pokazuję go tutaj, bo najlepiej odpowiada na pytanie, które słyszę najczęściej: „dobrze, ale czy potrafisz to dowieźć do końca?“.

Co to właściwie jest

Aplikacja webowa, w której podajesz listę składników i kilka preferencji, a w kilka sekund dostajesz konkretny przepis: nazwę, listę składników z zaznaczeniem, co już masz, kroki, makro, listę zakupów i wskazówkę, co zużyć w pierwszej kolejności. Bez rejestracji, bez instalacji, w dwóch językach.

Ekran startowy WTFridge — wpisujesz resztki z lodówki i ustawiasz preferencje

Serce aplikacji: dynamiczny builder promptu

Cała wartość siedzi w miejscu, którego użytkownik nie widzi. Backend to jedna funkcja serverless (Netlify Functions), która działa jako bezpieczny proxy do modelu językowego — klucz API nigdy nie trafia do przeglądarki. Jej najważniejsza część to dynamiczny builder promptu, który z dwunastu zmiennych wejściowych składa precyzyjną instrukcję dla modelu:

twarde ograniczenia dietetyczne (keto, wege, low FODMAP, alergie),
dostępny sprzęt (piekarnik, air fryer, thermomix…),
tryb zakupów (zero zakupów vs. maksymalnie trzy produkty),
cel żywieniowy (więcej białka, mniej węgli, comfort food…),
limit czasu, poziom trudności, liczba porcji, preferencje smakowe.

Model zawsze zwraca ustrukturyzowany JSON o sztywnym schemacie, a każda odpowiedź jest walidowana względem zdefiniowanego w TypeScripcie interfejsu. Jeśli coś nie pasuje do schematu — użytkownik nie zobaczy rozjechanego ekranu, tylko czytelny komunikat. To ta sama dyscyplina, którą znam z przygotowalni: plik albo jest poprawny, albo nie idzie na maszynę.

Własny design system, nie gotowy UI kit

Zamiast sięgnąć po gotowy zestaw komponentów, zbudowałem w Tailwindzie własny system: pięć autorskich palet kolorów, ciepłe cienie, własne animacje wejścia, typografię opartą na Instrument Serif i Inter, spójny rytm ośmiu pikseli i miękkie zaokrąglenia. Zero zależności UI — poza ikonami nic nie jest cudze. Dzięki temu aplikacja ma charakter, a nie wygląda jak każdy inny projekt na tym samym boilerplate.

Formularz generatora to sześć niezależnych sekcji z różnymi typami interakcji — chip input ze skrótami klawiaturowymi, multi-toggle sprzętu, wybór binarny „poziomu desperacji“, profile dietetyczne z polem na własne wykluczenia. Całość ma prowadzić laika za rękę, nie onieśmielać go liczbą opcji.

Decyzje, które podjąłem świadomie

Dobry produkt to w równym stopniu to, czego się nie dodaje. Kilka decyzji, za którymi stoi konkretne uzasadnienie:

Bez bazy danych. Zapisane przepisy trzymam lokalnie, w przeglądarce. Przy tej skali to właściwy wybór: brak kont, brak danych osobowych do pilnowania, zero infrastruktury. Aplikacja działa offline.
Własny system dwujęzyczności zamiast ciężkiej biblioteki — ponad 120 kluczy tłumaczeń w PL i EN, z poprawną odmianą liczby mnogiej, język wykrywany automatycznie. Dwa języki nie potrzebują frameworka z dziesięcioma zależnościami.
OpenRouter zamiast wpięcia w jednego dostawcę — zmiana modelu to zmiana jednej zmiennej środowiskowej. Nie jestem zakładnikiem jednego API.
Pełna obsługa błędów i timeoutów — rozróżniam brak klucza, błąd po stronie modelu, timeout i pustą odpowiedź. Każdy przypadek ma swój czytelny komunikat.

Dlaczego to jest w tym portfolio

WTFridge to około 2500 linii TypeScriptu, dwanaście zmiennych sterujących promptem, dwa języki i zero zależności UI. Ale liczby są tu drugorzędne. Najważniejsze jest to, co ten projekt udowadnia: potrafię przejść całą drogę samodzielnie — od zauważenia realnego problemu, przez zaprojektowanie interfejsu i systemu wizualnego, po napisanie działającego kodu i wypuszczenie produktu, który po prostu działa. Grafik, który rozumie, jak zbudowana jest rzecz, którą projektuje, podejmuje po drodze lepsze decyzje.