Trzy dni. Tyle dostaliśmy od klienta — właściciela małej platformy logistycznej — żeby pokazać inwestorowi działający prototyp systemu do śledzenia zamówień i zarządzania flotą. Bez tego spotkanie miało sens tylko jako ćwiczenie z networkingu. Zdecydowaliśmy się podjąć.
To był pierwszy raz, kiedy przeprowadziliśmy cały cykl — od zera do wdrożonego MVP — z Claude Code jako głównym narzędziem developerskim. Piszemy o tym, bo wnioski są nieoczywiste.
Kontekst i stos technologiczny
Klient miał już prosty system w Excelu i kilka skryptów w Pythonie do raportowania. Potrzebował czegoś, co można pokazać na ekranie: panel admina, widok kierowcy, live tracking zamówień i eksport do PDF. Nic przełomowego — ale w trzy dni, od podstaw.
Wybraliśmy stos, który znamy i który się dobrze składa: Astro 4 na frontendzie (statyczne strony z wyspami React tam, gdzie potrzebna interaktywność), TypeScript wszędzie, PostgreSQL jako baza danych, Drizzle ORM i Hono jako lekki backend API. Całość na Railway — deployment w kilka minut.
Dlaczego Astro zamiast Next.js? Bo przy MVP najważniejsza jest szybkość strony i prostota. Astro generuje minimalne JavaScript, nie ma niepotrzebnego hydration na całej stronie. Przy prezentacji inwestorskiej ładowanie 80ms robi wrażenie. Next.js ma 3x więcej konfiguracji na start.
Jak wyglądał workflow z Claude Code
Nie używaliśmy Claude Code jako "autocomplete na sterydach". Używaliśmy go jako drugiego developera — z pełnym dostępem do repozytorium, możliwością edycji plików i uruchamiania komend.
Dzień pierwszy był w całości na architekturze i bazie danych. Napisaliśmy razem z Claude schema Drizzle dla pięciu tabel: orders, drivers, vehicles, stops, events. Claude zaproponował dodanie tabeli audit_log od razu — nie prosiliśmy o to, po prostu zwrócił uwagę, że inwestorzy często pytają o historię zmian. Dobry instynkt.
Drizzle migrations działały od pierwszego uruchomienia. To rzadkość przy ręcznym pisaniu — Claude pilnuje spójności typów między schematem a kodem TypeScript w czasie rzeczywistym.
Dzień drugi to API i integracja. Napisaliśmy 14 endpointów w Hono: CRUD na zamówieniach, assignment kierowców, aktualizacja statusów GPS, generowanie PDF przez Puppeteer. Claude Code radził sobie z każdym bez potrzeby tłumaczenia kontekstu od nowa — pamiętał cały projekt.
Kluczowa rzecz, której się nauczyliśmy: zamiast dawać Claude'owi ogólne zadania ("napisz endpoint do zamówień"), dawaliśmy mu konkretne requirements z przykładowymi danymi. "Endpoint POST /orders/assign przyjmuje { orderId: uuid, driverId: uuid }, sprawdza czy kierowca nie ma już 3 aktywnych zleceń, zwraca 409 jeśli tak". Efekt? Kod z pierwszego przejścia działał w 80% przypadków.
Iteracyjna pętla testowania
Zamiast pisać testy jednostkowe (brak czasu), przyjęliśmy podejście: napisz feature → uruchom → przetestuj ręcznie → popraw z Claude. Każda iteracja trwała 5–15 minut.
Claude Code ma tu przewagę nad ChatGPT czy Cursor: widzi błędy z terminala w kontekście. Kiedy PostgreSQL rzucał constraint violation z powodu nullable column w Drizzle schema, Claude widział pełny stack trace, wiedział który plik edytować i robił to od razu — bez kopiowania błędu, bez tłumaczenia kontekstu.
Zrobiliśmy w sumie ok. 40 takich iteracji przez trzy dni. Szacujemy, że każda iteracja zajmowałaby 2–3x dłużej bez Claude Code — głównie przez wyszukiwanie w dokumentacji i ręczne przepisywanie typów TypeScript.
Co zbudowaliśmy w 72 godziny
Po trzech dniach mieliśmy: panel admina z listą zamówień, filtrowaniem i statusami; widok kierowcy na mobile (PWA); mapę z lokalizacjami live (Leaflet.js + WebSocket); eksport PDF z podsumowaniem dnia; podstawowe auth przez JWT; deployment na Railway z subdomeną klienta.
Nie wszystko było idealne. Brak pełnych testów, brak obsługi edge cases w GPS gdy kierowca wchodzi w tunel, brak rate limitingu na API. Ale działało — i działało na żywo podczas prezentacji.
Inwestor zobaczył produkt, nie prezentację. Spotkanie skończyło się termsheetem.
Wnioski i co byśmy zrobili inaczej
Claude Code przyspiesza development, ale nie zastępuje decyzji architektonicznych. Kilka razy musieliśmy zatrzymać się i powiedzieć "nie, to zróbmy inaczej" — bo Claude optymalizował lokalnie, nie globalnie. Miał tendencję do dodawania abstrakcji tam, gdzie przy MVP wystarczy prosta funkcja.
Najlepiej sprawdził się przy: generowaniu boilerplate (routes, schema, typy), refactoringu gdy zmieniał się kontrakt API, debugowaniu błędów z pełnym kontekstem pliku.
Najgorzej przy: decyzjach o strukturze projektu, wyborze bibliotek (proponował zbyt wiele opcji), estymacji złożoności zadania.
Polecamy: pracuj z Claude Code na jednej funkcji na raz, trzymaj PR-y małe, rób commit po każdej działającej iteracji. I daj mu pełny kontekst na start — uruchom go w katalogu projektu z dostępem do wszystkich plików, nie wycinaj fragmentów do chatu.
Porozmawiajmy o Twoim projekcie
Jeśli masz pomysł na produkt i ograniczony czas lub budżet — to jest dokładnie nasz obszar. Budujemy MVP, prototypy i pierwsze wersje produktów dla małych i średnich firm. Piszemy do nas przez formularz kontaktowy na mkmlabs.pl lub bezpośrednio na mateusz.pilecki89@gmail.com. Pierwsze spotkanie jest bezpłatne.
Potrzebujesz podobnego rozwiązania?
Porozmawiajmy o Twoim projekcie
Pierwsza rozmowa jest bezpłatna. Opisz nam swój pomysł — odpowiemy w ciągu jednego dnia roboczego.
Umów bezpłatną rozmowę