Calendly w wersji dla zespołów kosztuje kilkaset złotych miesięcznie za funkcje, które w praktyce wykorzystuje się w 20%. Dla małego salonu, gabinetu czy firmy usługowej z 2-5 pracownikami to wydatek, który po roku przekracza koszt zbudowania własnego rozwiązania od zera. W tym artykule pokazuję, jak zaprojektować i wdrożyć minimalistyczny system rezerwacji online w Next.js i Supabase, który robi to, czego naprawdę potrzebujesz, i nic więcej.
Szybka odpowiedź
Własny system rezerwacji online zbudujesz w Next.js (frontend + API routes) i Supabase (baza PostgreSQL, autoryzacja, realtime). Podstawowa wersja z kalendarzem, blokowaniem slotów i powiadomieniami e-mail wymaga 15-30 godzin pracy programisty i działa bez opłat miesięcznych, w przeciwieństwie do Calendly czy podobnych platform SaaS.
Najważniejsze wnioski
- Supabase w planie darmowym wystarcza dla firmy obsługującej do kilkuset rezerwacji miesięcznie, bez limitów typowych dla SaaS.
- Model danych oparty na tabelach
services,staff,slotsibookingsskaluje się bez przebudowy nawet przy dodaniu nowych lokalizacji. - Realtime subscriptions w Supabase eliminują problem podwójnych rezerwacji bez pisania własnego mechanizmu blokad.
- Next.js API Routes obsłużą całą logikę biznesową (walidację terminów, wysyłkę e-maili) bez potrzeby osobnego backendu.
- Rezerwacje bez gotowych systemów oznaczają pełną kontrolę nad UX i brandingiem formularza, czego Calendly nie daje.
Dlaczego warto odejść od Calendly i podobnych platform
Gotowe narzędzia typu Calendly, Booksy czy Setmore sprawdzają się, gdy potrzebujesz czegoś działającego w 15 minut i nie masz zasobów programistycznych. Problem zaczyna się, gdy firma rośnie albo potrzebuje niestandardowej logiki, na przykład rezerwacji zależnych od typu usługi i lokalizacji jednocześnie, rabatów dla stałych klientów widocznych już na etapie wyboru terminu, czy integracji z wewnętrznym systemem CRM.
W jednym z projektów, które prowadziliśmy w EXOLAB, klient z branży beauty płacił za Calendly Teams około 800 zł miesięcznie i dodatkowo za integrację z Zapierem, żeby połączyć rezerwacje z arkuszem Google do rozliczeń pracowników. Po migracji na własny system rezerwacji online koszt utrzymania spadł do zera złotych miesięcznie (Supabase Free Tier), a logika rozliczeniowa trafiła bezpośrednio do bazy danych bez pośredników.
Kluczowa różnica to nie tylko cena. To też brak zależności od trzeciej strony, która może zmienić cennik, ograniczyć funkcje w darmowym planie albo po prostu zniknąć z rynku.
| Kryterium | Calendly (plan Teams) | Własny system (Next.js + Supabase) |
|---|---|---|
| Koszt miesięczny | 200-800 zł zależnie od liczby użytkowników | 0 zł do pewnego progu ruchu |
| Personalizacja UX | Ograniczona do szablonów | Pełna kontrola nad interfejsem |
| Integracja z własnym CRM | Wymaga Zapiera lub API premium | Bezpośredni dostęp do bazy danych |
| Czas wdrożenia | Kilka minut | 15-30 godzin pracy programisty |
| Utrzymanie | Zero, ale zależność od dostawcy | Wymaga drobnych poprawek po starcie |
Projektowanie modelu danych pod kalendarz dla usług
Najczęstszy błąd przy budowie własnego systemu rezerwacji to zbyt uproszczony model danych. Jeśli od razu zaprojektujesz strukturę pod jedną osobę i jeden typ usługi, każde rozszerzenie (nowy pracownik, nowa lokalizacja) wymusi przebudowę logiki.
Sprawdzony model dla małej firmy usługowej opiera się na czterech tabelach. Tabela services przechowuje typy usług z czasem trwania i ceną. Tabela staff zawiera pracowników wraz z przypisanymi usługami, które mogą wykonywać. Tabela availability definiuje harmonogram pracy każdego pracownika w formie reguł (np. poniedziałek-piątek 9-17), z których generowane są dostępne sloty. Tabela bookings przechowuje faktyczne rezerwacje z referencją do usługi, pracownika i klienta.
Taki układ pozwala od pierwszego dnia obsłużyć scenariusz, w którym klient wybiera usługę, system pokazuje tylko pracowników uprawnionych do jej wykonania, a dostępność liczona jest dynamicznie na podstawie reguł harmonogramu minus już zajęte sloty. W Supabase ta logika sprowadza się do jednego zapytania SQL z JOIN-ami, bez potrzeby ręcznego przetwarzania w kodzie aplikacji.
Obsługa stref czasowych i buforów między wizytami
Praktyczny detal, który łatwo przegapić: każda usługa powinna mieć zdefiniowany bufor przed i po wizycie (np. 10 minut na sprzątanie stanowiska). Zapisanie tego jako pola buffer_minutes w tabeli services pozwala automatycznie blokować sloty bezpośrednio sąsiadujące z rezerwacją, bez ręcznej korekty grafiku przez pracownika.
Implementacja rezerwacji w Next.js krok po kroku
Architektura aplikacji w Next.js dzieli się na dwie części: publiczny formularz rezerwacji dostępny dla klientów oraz panel administracyjny do zarządzania grafikiem i podglądu rezerwacji. Obie części mogą korzystać z tego samego klienta Supabase, ale z różnymi poziomami uprawnień skonfigurowanymi przez Row Level Security.
Formularz rezerwacji w praktyce to trzy kroki: wybór usługi, wybór terminu z listy dostępnych slotów, potwierdzenie danymi kontaktowymi. Logikę generowania dostępnych slotów najlepiej umieścić w API Route Next.js, które odpytuje bazę, odfiltrowuje zajęte terminy i zwraca gotową listę do frontendu. Dzięki temu cała logika biznesowa zostaje po stronie serwera, a frontend jedynie renderuje wynik.
Krytyczny moment to zapis rezerwacji. Żeby uniknąć sytuacji, w której dwóch klientów rezerwuje ten sam slot w tym samym momencie, warto skorzystać z transakcji bazodanowej z warunkiem unikalności na kombinacji pracownik-data-godzina. Supabase pozwala to zrobić przez unique constraint w PostgreSQL, co gwarantuje, że druga próba zapisu tego samego slotu zwróci błąd, a nie utworzy duplikat.
Po zapisaniu rezerwacji warto wywołać webhook uruchamiający wysyłkę e-maila potwierdzającego, na przykład przez Resend albo Postmark. Koszt tych usług w niskim wolumenie wysyłek jest zwykle darmowy lub symboliczny, znacznie niższy niż opłaty za powiadomienia w gotowych platformach SaaS.
Utrzymanie i rozwój systemu bez opłat miesięcznych
Największą obawą przy rezygnacji z gotowych systemów jest pytanie, co się stanie, gdy ruch wzrośnie. Supabase w darmowym planie oferuje 500 MB przestrzeni bazy danych i 50 tysięcy aktywnych użytkowników miesięcznie, co dla małej firmy usługowej (nawet z kilkuset rezerwacjami tygodniowo) jest limitem odległym od realnego zapotrzebowania. Next.js hostowany na Vercel w planie Hobby również obsłuży ten ruch bez kosztów, o ile aplikacja nie generuje ekstremalnego obciążenia serwerowego.
Jeśli firma rzeczywiście urośnie do skali wymagającej płatnego planu, koszty Supabase Pro (25 dolarów miesięcznie) i Vercel Pro (20 dolarów miesięcznie) wciąż są niższe niż licencje na rozbudowane systemy rezerwacyjne z dodatkami premium. Różnica jest taka, że płacisz za realną infrastrukturę, a nie za funkcje, które nigdy nie zostaną wykorzystane.
Rozwój systemu w kolejnych miesiącach zwykle idzie w stronę integracji płatności online (Stripe), przypomnień SMS (Twilio) oraz panelu analitycznego pokazującego obciążenie poszczególnych pracowników. Każdy z tych elementów można dodać niezależnie, bez przebudowy istniejącej architektury, o ile model danych został zaprojektowany prawidłowo od początku.
Słowniczek
Row Level Security (RLS)
Mechanizm w PostgreSQL i Supabase pozwalający definiować reguły dostępu do wierszy tabeli na poziomie bazy danych, niezależnie od logiki aplikacji. Umożliwia np. ograniczenie widoczności rezerwacji tylko do właściciela konta.
API Route
Funkcja serwerowa w Next.js działająca pod dedykowanym adresem URL, obsługująca logikę backendową (np. zapis rezerwacji) bez potrzeby budowania osobnego serwera.
Realtime subscription
Funkcja Supabase pozwalająca aplikacji nasłuchiwać zmian w bazie danych w czasie rzeczywistym, np. natychmiastowe odświeżenie listy dostępnych slotów po dokonaniu rezerwacji przez innego użytkownika.
Slot
Pojedyncza jednostka czasu dostępna do rezerwacji, wygenerowana na podstawie harmonogramu pracownika i czasu trwania wybranej usługi.
Najczęściej zadawane pytania
Czy budowa własnego systemu rezerwacji online jest tańsza niż Calendly?
Przy dłuższej perspektywie tak. Calendly Teams kosztuje od kilkuset do kilku tysięcy złotych rocznie zależnie od liczby użytkowników, a własne rozwiązanie na Next.js i Supabase w darmowym planie obsłuży małą firmę bez opłat miesięcznych. Koszt to jednorazowa praca programisty, zwykle 15-30 godzin dla podstawowej wersji.
Jaki stack technologiczny wystarczy do zbudowania systemu rezerwacji?
Next.js jako framework frontendowy i backendowy w jednym, Supabase jako baza danych PostgreSQL z wbudowaną autoryzacją i webhookami, oraz Resend lub podobna usługa do wysyłki e-maili. To wystarcza na kalendarz dla usług obsługujący kilka osób i kilkanaście typów wizyt.
Czy taki system poradzi sobie z synchronizacją terminów w czasie rzeczywistym?
Tak, Supabase oferuje Realtime subscriptions, które pozwalają na natychmiastowe blokowanie slotu w momencie rezerwacji przez innego klienta. To eliminuje problem podwójnych rezerwacji bez potrzeby budowania własnego mechanizmu websocketów.
Czy własny system rezerwacji wymaga stałego wsparcia programisty?
Po wdrożeniu podstawowa wersja działa samodzielnie i nie wymaga ciągłej opieki. Warto zarezerwować budżet na drobne poprawki po pierwszych tygodniach użytkowania oraz na ewentualne rozszerzenia, np. integrację z płatnościami czy SMS-ami.
Czy to rozwiązanie nadaje się dla firmy z wieloma pracownikami i lokalizacjami?
Tak, przy odpowiednim modelu danych od początku (tabele resources, locations, staff) system skaluje się bez przepisywania architektury. Kluczowe jest zaplanowanie tych relacji już na etapie projektowania bazy, a nie dodawanie ich później.