Od pustego ekranu do pierwszego klienta na żywo — w osiem dni.
Fit in de Buurt to platforma leadów dla lokalnych studiów sportowych: landing page’e, które konwertują, portal do obsługi oddzwonionych leadów, przewodnik po kodzie pocztowym i fakturowanie wokół tego. Projekt, budowa, baza danych, hosting i utrzymanie — zbudowane solo.
Na żywo na fitindebuurt.nl · Row-level security na wszystkim prywatnym · Next.js 16, React 19, Supabase
Problem
Małe studio sportowe reklamuje się lokalnie, kieruje ludzi na Instagram lub ogólną stronę i tam ich traci. Kto odpowie, trafia przez DM, mail albo wiadomość; właścicielka pamięta w głowie, do kogo ma oddzwonić. Dwa dni później połowa jest zapomniana, a zainteresowanie znikło.
Trzy rzeczy, które do tego istnieją, rozwiązują każda tylko kawałek. Kreator stron dostarcza stronę bez follow-upu. CRM jest zbyt ciężki dla kogoś z garstką leadów miesięcznie. Linktree nie daje żadnego wglądu. A wszystko, co działa, umieszcza dane osobowe jej klientów tam, gdzie nie ma nad tym kontroli.
Czym się stało
Jedna platforma obsługująca trzy rodzaje odwiedzających naraz — sportowca, studio i operatora.
Dla sportowca
Strona główna to przewodnik: wpisz kod pocztowy i zobacz, które studia, siłownie, salony i gabinety są najbliżej, z odległością, opiniami i przyciskiem do systemu rezerwacji lub strony leadów. Bez cookies, bez konta, bez zapisywania tego, czego ktoś szuka.
Dla studia
Własna strona leadów na nazwa.fitindebuurt.nl i fitindebuurt.nl/nazwa, zbudowana z bloków i dopasowana do identyfikacji. Kto zostawi numer, ląduje od razu w portalu, z mailem obok. Ten portal ma jedną listę: do kogo dzwonię. Na lead system śledzi próby połączeń, pozwala odłożyć z notatką i oznaczyć jako wygrany lub odrzucony.
Dla operatora
Edytor, w którym buduję i publikuję stronę klienta, statystyki na wersję tej strony oraz fakturowanie z subskrypcjami, numeracją, PDF-ami i nocnym zadaniem cron.
Nigdzie nie ma przycisku dzwonienia ani linku tel:. To cała idea: odwiedzający zostawia dane, a studio oddzwania. Dzięki temu właścicielka wie, kto był zainteresowany, nawet gdy rozmowa nie dojdzie od razu.
Cztery decyzje, które definiują projekt
Decyzje, które przenikają cały kod — i stanowią różnicę między gotowym a zbytym.
Rozdział między klientami jest w bazie danych, nie w interfejsie
Każda strona ma jednego właściciela. Row-level security w Postgres decyduje, kto widzi który wiersz; aplikacja nie może tego obejść, ja też nie. Zestaw testów używa prawdziwych danych dwóch właścicieli, by próbować czytać, zmieniać i usuwać leady drugiego. Bez tego zielonego testu nic nie idzie na produkcję.
Treść strony żyje w dwóch miejscach, celowo
Szablon to typowany plik kończący się satisfies LandingPagina — brak tekstu i build się wywala. To, co zmieniam w edytorze, staje się overlayem w bazie i nakłada się na szablon przy renderowaniu. Zachowuję gwarancje kompilatora i mogę zmieniać teksty bez deployu.
Publikuje się pod nazwą, liczby należą do wersji
Każda publikacja to niezmienny wiersz w pagina_versies. Dzienne liczniki pamiętają, co policzono na wersję, więc widzę, co dała "Krótszy hero" wobec "Promocji letniej", i przywracam starą wersję jako szkic jednym kliknięciem.
Wszystko po niderlandzku, aż do bazy danych
Kolumny nazywają się belpogingen, snooze_tot, weggedrukt_op. Czyta się tak samo dla klienta i dla mnie i utrzymuje mały dystans między tym, co mówimy w rozmowie, a tym, co jest w kodzie.
Trzy elementy warte podkreślenia
Miejsca, w które poszło najwięcej myślenia i budowania.
Edytor stron
Po lewej podgląd na żywo, po prawej strona z góry na dół: jeden panel na blok ze wszystkim, co do niego należy. Teksty edytujesz w samym podglądzie — wskaż, kliknij, pisz — a odwiedzający dostaje dokładnie ten sam HTML. Kolor akcentu żyje w jednej zmiennej CSS; color-mix wyprowadza pięć odcieni, więc każdy blok pasuje do każdej identyfikacji.
Przewodnik po kodzie pocztowym
Kody pocztowe idą do serwera lokalizacji Kadastru (PDOK): otwarty, darmowy, bez klucza. Wynik przechowujemy we własnej tabeli, drugi odwiedzający z tym samym kodem nie kosztuje zapytania. Postgres liczy odległość i zwraca tylko studia spełniające wszystkie warunki. Z odwiedzającego nie zachowujemy nic: żadnego cookie, żadnego IP.
Fakturowanie
Subskrypcje na klienta, automatyczne wersje robocze z nocnego przebiegu, numeracja faktur, która nie może przeskakiwać, kwoty w groszach, VAT na wiersz i PDF w magazynie. Wysłana faktura jest zamrożona: triggery bazy odrzucają każdą zmianę, bo wysłana faktura ma pozostać taka sama przez siedem lat.
Potrzebujesz czegoś takiego dla swojej firmy?
Jak to jest złożone
Jeden projekt Next.js obsługuje cztery rodzaje odwiedzających, rozdzielone grupami tras: przewodnik, strony marketingowe, landing page’e klientów i część zalogowaną. Subdomeny idą przez proxy.ts, który odświeża sesję Supabase i zamyka wszystko za logowaniem.
| Warstwa | Wybór |
|---|---|
| App | Next.js 16 (App Router), React 19, TypeScript strict |
| Style | Tailwind CSS 4, własne komponenty, w pełni niderlandzki interfejs |
| Dane + auth | Supabase (Postgres, auth, storage), region Frankfurt |
| Walidacja | Zod, po obu stronach i na zmiennych środowiskowych |
| Resend, pięć maili transakcyjnych z jednym układem | |
| @react-pdf/renderer, faktury w Supabase Storage | |
| Hosting | Vercel, wildcard *.fitindebuurt.nl, zadania cron, preview na push |
| Sekrety | Doppler; żadnego klucza w repo |
| Monitoring | Sentry, tylko na produkcji |
- Dwa nocne zadania na Vercel za wspólnym sekretem: 06:00 fakturowanie, 04:00 sprzątanie wygasłych zgłoszeń.
- Bez nazwisk, numerów telefonu i adresów e-mail w logach czy komunikatach błędów, bez adresów IP w statystykach.
- Leady zapisywane wyłącznie po stronie serwera — przeglądarka nie ma prawa zapisu do bazy.
- Odłożony lead wraca sam: snooze to nie status, lecz data, żadnego zadania w tle, które może stanąć.
Jakość i sposób pracy
Jedna komenda to brama: npm run check uruchamia typecheck, ESLint bez ostrzeżeń, Prettier, wszystkie testy jednostkowe i pełny build. Co przez to nie przejdzie, nie jest zgłaszane jako gotowe. Husky i lint-staged robią to samo przy każdym commicie, GitHub Actions powtarza przy każdym pushu.
| Co | Skala |
|---|---|
| Kod | 265 plików, ± 33 000 linii TypeScript |
| Baza danych | 27 migracji, 20 tabel, RLS na wszystkim prywatnym |
| Testy jednostkowe | 412, w 37 plikach |
| Testy przeglądarkowe (Playwright) | 52, w 9 plikach |
| Szablony i bloki | 8 szablonów, 12 wielokrotnych bloków |
| Commity | 94, w osiem dni |
Testy przeglądarkowe robią to, co człowiek
Zaloguj się, przechwyć lead, odłóż go, wyłącz blok w edytorze, opublikuj i sprawdź, że strona publiczna też się zmienia. Właśnie tam są błędy, których typecheck i testy jednostkowe nie widzą.
Znajdowalność jest ustalona w czterech miejscach
robots.ts (z dwudziestoma trzema crawlerami AI po nazwie), sitemap pobierająca strony klientów z bazy, wygenerowany /llms.txt z całą witryną w markdown i dane strukturalne na typ strony — nigdy więcej niż to, co na samej stronie.
Zbudowane z pomocą AI, ale nie na chybił trafił
Każda część została najpierw spisana jako plan w repo — dlaczego, jakie fazy, jakie kompromisy — a potem zbudowana. Stałe ustalenia żyją w pliku reguł czytanym w każdej sesji. Testy, typy i row-level security to hamulec.
Gdzie to teraz jest
Strona działa, pierwszy prawdziwy klient jest na żywo i w przewodniku, a fakturowanie jest gotowe na jego pierwszą subskrypcję.
- Widok mapy i osobne strony przeglądowe na typ i miejscowość
- Zweryfikowane opinie Google
- Eksport leadów
- Uwierzytelnianie dwuskładnikowe
- Testy A/B na dwóch opublikowanych wersjach naraz
Od pomysłu do platformy na żywo
Oprogramowanie na miarę, które trwa.
Platforma leadów, portal, sklep czy narzędzie wewnętrzne — zbudowane z testami, typami i prywatnością jako fundamentem. Porozmawiajmy o tym, czego potrzebujesz.