Darmowy plan hostingu wyklucza projekt, za który zapłacono wykonawcy. Takich progów w repo jest pięć

Wygenerowany projekt sklepu zbudował się bez jednego błędu, przeszedł odbiór i stoi na domenie klienta. W .env.example jest pięć kluczy do pięciu usług zewnętrznych i wszystkie pięć kont założono na planach za zero złotych. Jeden z tych planów usypia bazę po tygodniu bez ruchu, drugi gubi potwierdzenia zamówień po setnym mailu w dobie, a trzeci wyklucza ten projekt ze swojego regulaminu w całości – nie dlatego, że sklep sprzedaje, ale dlatego, że wykonawca wziął za niego pieniądze.

W ofercie była jedna linijka: „hosting i konta usług po stronie klienta”. To zdanie nie jest wyceną, tylko przeniesieniem na klienta decyzji, których nikt nie podjął. Model wpina usługi, bo tak wygląda większość przykładów, na których się uczył – i wpina je w wariancie darmowym, bo taki jest w dokumentacji pierwszy. Żadna z tych decyzji nie jest zapisana w miejscu, w którym ktoś ją zobaczy przed podaniem ceny.

Inwentarz usług z repozytorium: trzy komendy przed podaniem ceny

Lista usług nie jest w dokumentacji projektu, bo generowane projekty rzadko ją mają. Jest w trzech miejscach w kodzie i da się ją wyciągnąć szybciej, niż trwa rozmowa o cenie.

# 1. Klucze i adresy usług - nazwy zmiennych mówią, co jest wpięte
rg -o '^[A-Z0-9_]+(?==)' .env.example .env.local .env.production 2>/dev/null | sort -u

# 2. Pakiety klienckie dostawców - jeden pakiet to jedno konto i jeden próg
rg -o '"(@?[a-z0-9@/._-]*(resend|clerk|supabase|stripe|sentry|cloudinary|algolia|twilio|mapbox)[a-z0-9@/._-]*)"' package.json

# 3. Hosty wyjściowe wywołane z kodu - to łapie usługi bez pakietu, wołane przez fetch
rg -oI 'https?://[a-z0-9.-]+\.[a-z]{2,}' --glob '!node_modules' --glob '!*.lock' \
  | sed -E 's#.*https?://([^/]+).*#\1#' | sort | uniq -c | sort -rn | head -30

Trzecia komenda jest tą, która zwykle dopisuje do listy coś, czego nie było w dwóch pierwszych: osadzoną mapę, skrypt zgód na pliki cookie, webhook do narzędzia analitycznego. Każdy host z tego wyniku, który nie należy do klienta, jest osobnym kontem, osobnym regulaminem i osobnym progiem. Dopóki nie ma ich na kartce, wycena obejmuje tylko to, co widać w przeglądarce.

Inwentarz ma wartość tylko wtedy, gdy odtworzy go ktoś poza swoim autorem – przy następnej wycenie, przy przekazaniu projektu albo w zastępstwie. To jest wymóg stawiany opisowi procesu, nie notatce: procedura, którą wykona osoba, która jej nie pisała, podaje komendy i miejsca do sprawdzenia, a nie samą intencję. Trzy komendy powyżej są w tej formie celowo.

Progi pięciu usług, które generatory wpinają najczęściej

Poniższe wartości to stan cenników na 4 listopada 2026, odczytany ze stron dostawców. Progi zmieniają się częściej niż raz w roku, więc data odczytu jest częścią informacji, a nie formalnością – i z tego samego powodu w ofercie zapisuje się ją obok liczby.

Ostatni wiersz pokazuje, jak tanio bywa usunąć próg, zamiast go wyceniać. Mapa interaktywna z własnymi znacznikami ma licznik zdarzeń i stawkę po przekroczeniu, a ta sama lokalizacja wstawiona przez komponent osadzony limitu nie ma: Embed, Maps SDK i metadane Street View są bez limitu i bez opłat. Jeśli strona kontaktowa pokazuje jeden pinezkowy adres, droższy wariant nie daje klientowi niczego poza pozycją w rachunku.

Klauzula o użyciu komercyjnym nie pyta, czy strona sprzedaje

Najdroższy z tych progów nie jest progiem liczbowym. Regulamin Vercela stawia sprawę tak: zespoły na planie Hobby mogą korzystać z platformy wyłącznie w celach niekomercyjnych i osobistych, a każde użycie komercyjne wymaga planu Pro albo Enterprise. Decydujące jest to, jak zdefiniowano samo użycie komercyjne: jest nim każde wdrożenie służące korzyści finansowej kogokolwiek zaangażowanego w jakąkolwiek część produkcji projektu, w tym opłaconego pracownika lub konsultanta, który pisał kod.

Ta definicja obejmuje sytuację, w której strona nie ma koszyka, nie ma reklam i nie zbiera ani złotówki. Wystarczy, że ktoś dostał fakturę za jej napisanie. W tym samym miejscu dostawca wylicza przykłady, które przesądzają sprawę jeszcze szybciej – reklamowanie sprzedaży produktu lub usługi oraz przyjmowanie zapłaty za stworzenie, aktualizację albo hosting strony – i podaje jeden wyjątek: prośba o darowizny użyciem komercyjnym nie jest.

Praktyczne skutki są dwa i oba dotyczą etapu przed podpisaniem umowy, nie po. Pierwszy: wdrożenie demonstracyjne pokazywane klientowi w trakcie wyceny jest już objęte tą definicją, bo powstaje w ramach płatnej pracy. Drugi: konto, na którym stoi projekt, ma od pierwszego dnia należeć do klienta i być opłacane jego kartą, a wykonawca ma w nim być członkiem zespołu. Kolejność odwrotna – najpierw konto wykonawcy „na razie”, potem migracja po odbiorze – oznacza przenoszenie domeny, zmiennych środowiskowych i integracji w momencie, w którym projekt jest już na produkcji i nikt nie ma na to zarezerwowanych godzin.

Projekt na darmowej bazie usypia po tygodniu bez ruchu

Dla stron o małym ruchu groźniejszy od limitu wielkości jest warunek aktywności. Dostawca bazy zapisuje go wprost: darmowe projekty są wstrzymywane po tygodniu bezczynności, a wstrzymania nie stosuje się do projektów na planach płatnych. Limit 500 MB na stronie firmowej z czterema formularzami nie zostanie ruszony przez lata. Tydzień ciszy w ruchu zdarzy się w pierwszym kwartale.

Trafia to w konkretne typy zleceń, i są to typy częste: witryna firmy sezonowej, serwis B2B z kilkunastoma wejściami w miesiącu, strona wydarzenia pomiędzy edycjami, a także środowisko testowe, które stoi obok produkcyjnego i bywa odwiedzane raz na kilka tygodni. Objaw po stronie klienta nie wygląda na problem konta: pierwszy użytkownik po przerwie dostaje błąd serwera albo puste listingi, bo zapytania do bazy nie mają z czym się połączyć. Zgłoszenie przychodzi jako „strona nie działa”, a przyczyna jest w panelu usługi, nie w kodzie.

W wycenie to jedna decyzja, nie zestaw: albo projekt dostaje plan płatny od startu, albo trzeba przyjąć, że pierwszy wpis po przerwie zostanie obsłużony błędem i wymaga ręcznego wznowienia. Druga droga jest możliwa i czasem rozsądna, pod warunkiem że klient wie o niej przed podpisaniem umowy, a nie dowiaduje się w styczniu.

Limit 100 maili na dobę nie wywala builda, tylko gubi potwierdzenie zamówienia

Progi dzielą się na te, które przestają działać głośno, i te, które przestają działać cicho. Pierwsze zatrzymują wdrożenie albo zwracają stronę błędu i trafiają do zgłoszenia tego samego dnia. Drugie nie zatrzymują niczego. Limit maili transakcyjnych jest najczystszym przykładem drugiej kategorii, bo nadawca nie jest odbiorcą: nikt w firmie nie zauważy braku maila, którego miał dostać klient.

Generowany kod obsługi formularza ma prawie zawsze ten sam kształt i to on zamienia odrzucone żądanie w brak informacji:

// wersja z generatora: wynik wysyłki nie jest nigdzie sprawdzany
await resend.emails.send({ from, to, subject, html });
return Response.json({ ok: true });

Klient HTTP dostawcy nie rzuca wyjątku przy odrzuceniu z powodu limitu – oddaje obiekt z polem błędu, który powyższy kod wyrzuca do kosza. Formularz pokazuje użytkownikowi potwierdzenie, odpowiedź ma kod 200, a mail nie poszedł. Poprawka jest krótka i jej sens polega na tym, że informacja o nieudanej wysyłce zostaje w systemie klienta, a nie u dostawcy:

const { data, error } = await resend.emails.send({ from, to, subject, html });
if (error) {
  // 1. zapis do bazy: komu, kiedy, z jakim powodem odmowy
  await zapiszNieudanaWysylke({ to, subject, powod: error.name, tresc: error.message });
  // 2. sygnał dla zespołu klienta, kanałem innym niż ten, który właśnie padł
  await powiadomDyzurnego(`wysyłka odrzucona: ${error.name}`);
  // 3. dla użytkownika: uczciwy komunikat zamiast fałszywego potwierdzenia
  return Response.json({ ok: false, powod: 'mail_nie_wyszedl' }, { status: 502 });
}
return Response.json({ ok: true, id: data.id });

Przy tym samym dostawcy warto dołożyć drugą liczbę z tabeli do protokołu odbioru: retencja danych na planie darmowym wynosi 30 dni. Spór o to, czy zamówienie z października zostało potwierdzone mailem, rozstrzyga się w listopadzie – i jeśli jedynym dowodem był log u dostawcy, to w listopadzie tego dowodu już nie ma. Własny zapis każdej wysyłki w bazie klienta jest tańszy niż plan, który wydłuża retencję.

Trzy pozycje w ofercie zamiast jednej linijki o hostingu

Oferta, która ma wytrzymać pierwszy rachunek, mówi o każdej usłudze z inwentarza trzy rzeczy. Nie jest to więcej pracy – to ta sama wiedza, zapisana tam, gdzie klient ją zobaczy.

• Założony plan i jego cena. Nazwa planu, kwota miesięczna i waluta. Konto należy do klienta, wykonawca ma w nim dostęp członka zespołu. Bez tego pierwszego zdania klient traktuje stawkę jako element wynagrodzenia wykonawcy, a nie jako swój koszt stały.
• Założenie o ruchu, przy którym ta cena obowiązuje. Liczba wizyt, maili, logowań albo załadowań mapy w miesiącu. Założenie jest po to, żeby dało się wskazać moment, w którym przestało być prawdziwe – bez niego każda rozmowa o rachunku jest rozmową o tym, kto miał rację.
• Zdarzenie, które uruchamia przeliczenie. Przekroczenie progu, kampania, import danych, wejście na drugi rynek. To jedyna z trzech pozycji, która chroni wykonawcę: zapisane zdarzenie zamienia „podnosicie cenę” w „zadziałał warunek z oferty”.

Druga z tych pozycji jest tą, którą przy wycenie stron pomija się najczęściej, a przy wycenie automatyzacji nigdy: trzeba rozdzielić pozycje stałe od tych, które rosną z liczbą zdarzeń. Mechanizm jest identyczny niezależnie od tego, czy liczone są wywołania funkcji, maile czy ponowienia – rachunek rośnie z liczbą zdarzeń, a nie z wielkością zadania, i dlatego założenie o ruchu waży w ofercie więcej niż sama stawka.

Kolejność: co sprawdzić, zanim podasz cenę

Każdy krok poniżej kończy się liczbą albo zdaniem do oferty. Kolejność ma znaczenie, bo krok trzeci bez dwóch pierwszych nie ma czego liczyć.

• Wypisz usługi trzema komendami z początku tekstu i dopisz ręcznie to, co wchodzi przez panel, a nie przez kod: rejestrator domeny, certyfikat, skrzynka pocztowa.
• Dla każdej usługi odczytaj dzisiejszy próg ze strony dostawcy i zapisz datę odczytu. Cennik z pamięci albo z wpisu na blogu jest w tym miejscu bezwartościowy.
• Policz przewidywane zużycie z własnej liczby, nie z progu: wizyty miesięcznie razy liczba wywołań funkcji na wizytę, zamówienia razy liczba maili na zamówienie. Jeśli wynik jest w tym samym rzędzie wielkości co próg, usługa idzie do oferty jako plan płatny.
• Sprawdź warunki inne niż liczbowe: zakaz użycia komercyjnego, wstrzymanie po bezczynności, wymuszone oznaczenie dostawcy w interfejsie, długość sesji, retencja logów. Tutaj siedzą progi, których nie widać w żadnym liczniku.
• Oznacz progi ciche – te, których przekroczenie nie zwróci błędu użytkownikowi. Każdy z nich dostaje własny zapis w bazie klienta i powiadomienie kanałem niezależnym od usługi, która padła.
• Ustaw limit wydatków tam, gdzie dostawca na to pozwala, i powiedz klientowi, co się stanie po jego osiągnięciu. Limit bez tego zdania zamienia rachunek nie do przyjęcia w awarię nie do przewidzenia.

Decyzja, którą trzeba podjąć przed wysłaniem oferty, jest jedna: albo w ofercie stoi przy każdej usłudze plan, cena i założenie o ruchu, albo wykonawca milcząco bierze na siebie różnicę między progiem a rzeczywistością – razem z tym regulaminem, który już teraz wyklucza projekt pisany za wynagrodzenie. Na projektach oddanych wcześniej jest jedna rzecz warta sprawdzenia jeszcze dziś, bo nie wymaga zgody klienta ani dostępu do jego karty: która z usług z inwentarza stoi na koncie wykonawcy, a nie na koncie klienta. Ta lista jest zwykle krótka i zwykle niepusta.