Najpierw dla siebie czy od razu dla branży — jak zbudować pierwszą wersję, której użyje też konkurent?

Które decyzje o „wielu firmach” zapadają pierwszego dnia?

Sześć decyzji z tabeli niżej rozstrzyga, czy Twojej aplikacji użyje kiedykolwiek druga firma — i wszystkie zapadają, zanim powstanie pierwszy ekran. Żadna nie brzmi jak decyzja strategiczna: to sposób, w jaki zapisujesz rekord, sprawdzasz dostęp i nazywasz produkt.

W ponad 300 rozmowach o pomysłach na aplikację, które prowadziliśmy między czerwcem a wrześniem 2026 (ręczna klasyfikacja opisów pomysłu, stan 16.09.2026), 6 na 10 pomysłów to narzędzie dla firm z własnej branży, a 1 na 5 — platforma łącząca dwie strony branży.

Obie liczby znaczą dla pierwszej wersji to samo: w bazie musi istnieć pojęcie firmy, nie tylko pojęcie użytkownika. Użytkownik loguje się do aplikacji. Firma jest właścicielem danych, płatnikiem i stroną umowy — i to ona zostaje, gdy pracownik odchodzi.

Pilot u siebie tego nie unieważnia. Przez pierwsze tygodnie w bazie jest jedna firma, Twoja, i to jest w porządku. Różnica polega na tym, że siedzi tam jako firma z identyfikatorem, a nie jako założenie zaszyte w kodzie i w ekranach.

Dlaczego dorobienie „wielu firm” po starcie kosztuje więcej, niż wygląda?

Bo zmiana dotyka bazy, zapytań i ekranów naraz, a w bazie część zmian przepisuje całe tabele. Dokumentacja PostgreSQL 18 mówi to wprost: zmiana typu istniejącej kolumny normalnie przepisuje tabelę i jej indeksy, a przebudowa dużej tabeli chwilowo potrzebuje nawet dwa razy więcej miejsca na dysku (odczyt 16 września 2026).

Dodanie samej kolumny jest tanie i to właśnie myli. Kolumna ze stałą wartością domyślną nie wymusza przepisania tabeli. Ale dołożenie ograniczenia „wartość wymagana” każe przeskanować ją w całości, a polecenie zmieniające tabelę domyślnie bierze blokadę wyłączności — w tym czasie aplikacja tej tabeli nie czyta i nie zapisuje.

Najdroższa jest część, której w migracji nie widać: uzupełnienie historii. Do której firmy należy zlecenie sprzed dwóch lat, wystawione, gdy pojęcia firmy jeszcze nie było? To pytanie do Ciebie, nie do zespołu — i na kilku tysiącach rekordów zajmuje więcej niż sama zmiana schematu.

Druga pułapka dotyczy dostępu. Tabela wystawiona przez API bazy bez polityk na wiersze jest do odczytu i do zapisu dla każdej roli, która ma na niej uprawnienie — tak opisuje to dokumentacja Supabase (odczyt 16 września 2026). „Dostęp dorobimy na końcu” znaczy więc: do końca dane wszystkich firm stoją otworem.

Polityka nie jest też darmowa w działaniu. Działa jak warunek dokładany do każdego zapytania, więc kolumna, po której filtruje, musi mieć własny indeks i stać w nim na pierwszym miejscu. W przykładowym planie z dokumentacji odrzucenie 100 000 cudzych wierszy zajmuje 171 ms (odczyt 16 września 2026).

Trzecia droga — osobna kopia aplikacji dla każdej firmy — wygląda na ucieczkę od tych problemów i bywa najdroższa z całej trójki. Wytyczne Microsoftu o rozwiązaniach dla wielu najemców ujmują to jednym zdaniem: jeśli jeden najemca wymaga określonego kosztu infrastruktury, stu najemców wymaga zapewne stukrotności tej kwoty (odczyt 16 września 2026).

W cenniku widać to od pierwszego kroku: kolejny projekt bazy w planie Pro kosztuje od 10 USD miesięcznie (odczyt 16 września 2026). Gorsza jest reszta rachunku — każdą poprawkę wdrażasz osobno w każdej kopii, a wersje rozjeżdżają się po pierwszym pilnym wyjątku zrobionym dla jednej firmy.

Dla branży dochodzi warstwa, której pilot nie potrzebuje: rozliczenie cykliczne osobno dla każdej firmy. Moduł rozliczeń Stripe w wariancie „płacisz za to, czego używasz” kosztuje 0,7 % obrotu subskrypcyjnego, a płatność BLIK 1,6 % plus 1,00 zł (cenniki dla Polski, odczyt 16 września 2026).

Jak ta warstwa działa od środka, opisuje tekst o tym, jak działają płatności i subskrypcje w aplikacji dla firmy. Osobno policzone jest to, ile kosztuje miesięcznie utrzymanie aplikacji, z której korzysta 50 płacących firm.

Co celowo zostaje „tylko dla Ciebie” w pilocie?

Siedem rzeczy, które w pierwszej wersji świadomie zostają po Twojej stronie — nie dlatego, że są trudne, tylko dlatego, że bez drugiej firmy nikt nie wie, jak mają wyglądać. Każda z nich jest funkcją, nie fundamentem.

• Samodzielna rejestracja firmy z ulicy. Pierwszych partnerów zakładasz ręcznie i przy okazji słyszysz, co ich dziwi. Ekran samoobsługowy powstaje wtedy, gdy zakładanie firm zaczyna zjadać Twoje wieczory.
• Twoje stawki, statusy i szablony dokumentów. Zostają Twoje, ale jako wartości startowe w ustawieniach firmy, nie jako teksty w kodzie. Ta różnica kosztuje dzień pracy teraz i przebudowę ekranów później.
• Samoobsługowa zmiana planu i faktura. W pilocie fakturę wystawiasz ręcznie. Rozliczenie cykliczne wchodzi przy pierwszej firmie, która naprawdę płaci, a nie przy pierwszej, która obiecała.
• Integracje z Twoim własnym oprogramowaniem. Partner ma inny program magazynowy i inną księgowość. Obietnica „u Ciebie też podepniemy” złożona przed policzeniem jej jest długiem, nie zaletą.
• Porównania między firmami. Zestawienie „u kogo krok trwa dłużej” kusi najbardziej i najszybciej psuje zaufanie. Wymaga zgody partnerów i osobnej decyzji, co dokładnie w nim widać.
• Drobne role wewnątrz firmy partnera. W pilocie wystarczą dwie. Trzecia pojawia się, gdy partner powie, że u niego handlowiec nie może widzieć marży — i dopiero wtedy wiesz, jak ma działać.
• Kanał zgłoszeń. Wsparciem w pilocie jest Twój telefon. System zgłoszeń buduje się wtedy, gdy przestajesz pamiętać, kto o czym pisał i co komu obiecałeś.

Lista ma wspólny mianownik. Funkcję dokładasz wtedy, gdy wiesz, jak ma wyglądać, i kosztuje tyle, ile kosztuje. Fundament — czyja jest dana i kto ją widzi — dokładasz raz, bo poprawka dotyka wszystkiego, co już powstało.

Stąd próg do decyzji o pierwszej wersji: trzy firmy z branży, które nazwiesz z nazwy i w których wskażesz osobę do rozmowy. Jedna firma to Twój zwyczaj. Dwie to zbieg okoliczności. Trzy różne firmy z tym samym krokiem procesu to już proces branży.

Dlaczego trzy, a nie dziesięć? Bo koszt zbudowania wielofirmowego fundamentu jest jednorazowy i znany z góry, a koszt dorobienia go rośnie z każdym miesiącem historii w bazie. Przy trzeciej rozmowie odróżnisz już parametr od wyjątku, a czekanie nic do tego nie dodaje.

Reguła ma niewygodną drugą stronę. Jeśli po dwóch miesiącach pytań nadal masz jedną firmę, swoją, zbuduj narzędzie dla siebie i nie płać za warstwę wielu firm. Aplikacja dla branży bez trzech firm w rozmowach jest zakładem, nie planem.

Od ilu płacących firm ten fundament zwraca się w pieniądzach, liczy osobny tekst: od ilu firm aplikacja dla branży spina się jako drugie źródło przychodu. Sam zapis procesu, z którego powstaje zakres, opisuje tekst o tym, jak spisać swój proces dla całej branży.

Trzy rzeczy wchodzą u nas do pierwszej migracji i nie czekają na drugą firmę. Polityki dostępu na wierszach są włączone od początku, a automatyczna kontrola kodu odrzuca zmianę, która je wyłącza albo wpuszcza wszystkich.

Druga: rola operatora jest przypięta do identyfikatora użytkownika, nigdy do adresu e-mail — inaczej rejestracja „na ten sam adres” potrafi przejąć uprawnienia. Trzecia: ograniczenia nałożone na kolumny bez polityk na wiersze są pozorne i nie liczą się jako oddzielenie danych.

Konkurent jako partner: co go przekonuje, że to nie jest aplikacja Twojej firmy?

Konkurent nie pyta o architekturę. Pyta o cztery rzeczy: czy widzisz jego dane, czy aplikacja zmusi go do pracy po Twojemu, czy jutro nie odetniesz mu dostępu i czy jego ludzie będą codziennie logować się do czegoś z Twoim logo.

Na każdą z tych obaw odpowiada konkret w pierwszej wersji, nie zdanie w ofercie.

• Twoja firma jest w aplikacji jedną z firm. Jeśli Twoje rekordy są wyjątkiem bez wskazania właściciela, a Ty masz ekran, którego inni nie mają, partner zobaczy to przy pierwszej rozmowie o eksporcie danych.
• Rola operatora jest osobna i nazwana. Operator utrzymuje aplikację, administratorem danych jest partner u siebie. Te dwie role nie mogą być jedną tylko dlatego, że na starcie siedzą w jednej osobie.
• Prawda o dostępie technicznym zamiast obietnicy. Dokumentacja PostgreSQL 18 mówi wprost: superużytkownik i role z atrybutem pomijania polityk zawsze omijają zabezpieczenie na wierszach (odczyt 16 września 2026).
• Zdanie, które da się dotrzymać. „Technicznie nie mam dostępu” jest nieprawdą i partner z branży to sprawdzi. „Nie sięgam po Twoje dane bez Twojej zgody, a każde sięgnięcie zostawia ślad” jest sprawdzalne — i to zapisujesz.
• Jego sposób pracy jest parametrem. Wariant procesu ustawia się w jego firmie bez zmiany kodu. Jeśli wymaga zmiany kodu, to jest praca dodatkowa i tak ją nazywasz od początku, zanim padnie „przecież mówiłeś”.
• Neutralna nazwa i własna domena produktu. Pracownik partnera loguje się do produktu, a nie do firmy, z którą jego szef przegrywa przetargi. Adres w pasku przeglądarki jest argumentem, choć nikt tego nie powie wprost.

Jak pokazać partnerowi, że jego dane są oddzielone, i co może sprawdzić sam — to osobny temat: jak oddzielić dane konkurenta, żeby partner z branży zaufał. Ogólne zasady zebrane są w tekście o tym, które zasady bezpieczeństwa obowiązują od pierwszego dnia.

Czego nie obiecywać: wyłączności każdemu po kolei, ceny „na zawsze” i funkcji, której nie ma w planie prac. Partner z branży zna ten repertuar z własnych rozmów handlowych i wychwytuje go szybciej niż klient spoza branży.

Co zostaje po Twojej stronie, a co robi zespół, który buduje

Podział w tym temacie jest wyjątkowo ostry. Wszystko, co wymaga znajomości branży i ludzi w niej, jest po Twojej stronie. Wszystko, co wymaga znajomości bazy danych i uprawnień, jest po stronie zespołu technicznego — i nie da się tego zamienić miejscami.

Jedna pozycja jest wspólna. Ty decydujesz, co stoi na liście rzeczy zostawionych „tylko dla Ciebie” i kiedy z niej schodzi. Zespół pilnuje, żeby żadna z nich nie wsiąkła w fundament, bo stamtąd usuwa się je najdrożej.

Z czego taka aplikacja składa się warstwa po warstwie i co robi każda z nich, opisuje osobny tekst: z jakich warstw składa się aplikacja dla firmy.