Umowa z partnerem z branży na korzystanie z Twojej aplikacji — co musi być w niej zapisane?

Licencja czy dostęp do usługi — co właściwie sprzedajesz partnerowi?

Partner z branży najczęściej nie dostaje kopii programu, tylko konto w aplikacji, która stoi na Twoim serwerze. To jedno rozstrzygnięcie ustawia całą resztę umowy: przy dostępie przez przeglądarkę piszecie umowę o świadczenie usługi, przy kopii instalowanej u partnera — licencję z wymienionymi polami eksploatacji.

Dla drugiego wariantu prawo autorskie wymaga, żeby umowa wymieniała pola eksploatacji wyraźnie (art. 41), a dla programu komputerowego wylicza je osobno (art. 74).

Dwa przepisy o czasie zaskakują najczęściej. Licencja bez zapisanego terminu uprawnia do korzystania przez pięć lat na terytorium siedziby partnera, a potem prawo z niej wygasa (art. 66). Licencji udzielonej na dłużej niż pięć lat ustawa nie utrzymuje w nieskończoność — po tym okresie traktuje ją jak zawartą na czas nieoznaczony (art. 68).

Trzeci przepis dotyczy pieniędzy. Reguła, że twórcy należy się wynagrodzenie, gdy z umowy nie wynika co innego, do programów komputerowych nie ma zastosowania (art. 77 w związku z art. 43). Kwota i tryb jej zmiany muszą stać w umowie, bo ustawa ich nie podstawi.

Umowę z zespołem, który buduje aplikację, podpisujesz osobno i to w niej rozstrzyga się, czyje są prawa do kodu — opisuje ją tekst kto ma prawa do aplikacji zbudowanej na zlecenie. Tutaj chodzi o drugą umowę: Ty i firma z branży, która płaci za korzystanie.

Dziesięć elementów umowy z partnerem — i co psuje się bez każdego z nich

Dziewięć z dziesięciu zapisów ma oparcie w przepisie, jeden wyłącznie w praktyce umów. Kolejność w tabeli odpowiada kolejności, w jakiej partner będzie o nie pytał: najpierw co kupuje, potem ile to kosztuje, na końcu jak się z tego wyjdzie.

Dla umów zawartych po 12 września 2025 roku doszła jeszcze jedna zasada: postanowienie o dostępie do danych i o odpowiedzialności, narzucone jednostronnie mniejszej firmie, nie wiąże jej, jeśli jest nieuczciwe (art. 13 aktu w sprawie danych). Twardy wzorzec wobec małego partnera potrafi więc po prostu nie zadziałać.

Co z tych zapisów musi mieć odpowiednik w kodzie, a nie tylko w regulaminie, tłumaczy tekst RODO w aplikacji dla firmy.

Sześć pytań, które partner zada — i co w umowie na nie odpowiada

Firma z branży zadaje zawsze te same pytania i mniej więcej w tej kolejności, bo w tej kolejności rośnie jej ryzyko. Odpowiedź „ufaj mi” kosztuje podpis, odpowiedź z numerem paragrafu go zdobywa.

• „Czy zobaczysz moich klientów i moje ceny?” Przetwarzasz jego dane tylko po to, żeby usługa działała, i tylko na jego udokumentowane polecenie. W umowie: zamknięty cel przetwarzania, dziennik dostępu administratora, zakaz używania danych partnera do własnych celów handlowych.

• „Co się stanie z moimi danymi, gdy odejdę?” Eksport w formacie nadającym się do odczytu maszynowego, termin wydania, potwierdzone usunięcie kopii. Przy usłudze, z której partner korzysta przez sieć, okres wypowiedzenia uruchamiający przejście do innego dostawcy nie może przekraczać dwóch miesięcy, a samo przeniesienie — trzydziestu dni.

• „Podniesiesz cenę, gdy przeniosę na to całą firmę?” Bez trybu zmiany ceny każda podwyżka jest zmianą umowy, na którą partner musi się zgodzić. Zapisz więc tryb: najwyżej jedna zmiana w roku, zapowiedź z wyprzedzeniem, prawo wyjścia bez kary w oknie po zapowiedzi.

• „Co, jeśli padnie w szczycie sezonu?” Nie obiecuj więcej, niż obiecują Ci dostawcy infrastruktury. Jeden zobowiązuje się do 99,9 % miesięcznie, drugi do 99,99 % w granicach uzasadnionych handlowo starań — obie gwarancje obejmują wyłącznie plan Enterprise, a rekompensatą jest kredyt na usługę, nie odszkodowanie.

  99,9 % w miesiącu trzydziestodniowym to dopuszczalne 43 minuty przerwy: 43 200 minut razy jedna dziesiąta procenta. Partnerowi zapisz to, co dowieziesz — okna serwisowe, ścieżkę zgłoszeń, czas reakcji i formę rekompensaty.

• „Dasz mi wyłączność na moje miasto?” Domyślnie licencja jest niewyłączna, a wyłączna wymaga formy pisemnej pod rygorem nieważności. Wyłączność bez progu i bez terminu bierze od Ciebie jeden podpis, a zamyka resztę branży, dlatego wiąż ją liczbą i datą.

• „Co, jeśli sprzedasz aplikację albo przestaniesz ją rozwijać?” Zapisz, co dzieje się z umową przy zmianie właściciela i co partner dostaje, gdy usługa się kończy: okres przejściowy, eksport danych, rozliczenie opłaty za niewykorzystany okres.

Konkurent jako partner: wyłączność, której nie możesz dać każdemu

Wyłączność to jedyne miejsce w tej umowie, w którym interes konkurenta i Twój są wprost sprzeczne. On płaci za przewagę nad resztą branży, Ty sprzedajesz dostęp całej branży. Pozostałe zapisy da się uzgodnić, ten trzeba wycenić.

Działa zawężenie na trzech osiach naraz: zakres (miasto, segment, kanał sprzedaży), termin (dwanaście miesięcy) i próg, czyli minimalna liczba stanowisk albo kwota w okresie. Próg niedowieziony — wyłączność wygasa, a umowa biegnie dalej jako zwykły dostęp.

Dlaczego dwanaście miesięcy, a nie trzy lata? Bo rok to najkrótszy okres, w którym firma z branży przejdzie pełny cykl sezonowy i zdąży wyrobić próg, a zarazem najdłuższy, jaki możesz oddać, zanim zgłosi się druga firma z tego samego miasta z gotówką w ręku.

Konkurenta przekonują cztery rzeczy, których nie da się obiecać ustnie: oddzielenie jego danych od Twoich, zakaz odsprzedaży dostępu dalej, tryb zmiany ceny i wyjście z kompletem danych. Trzy pierwsze kosztują Cię zapis w umowie, czwarte — funkcję w aplikacji.

Samą rozmowę przed podpisem — czego konkurent się boi i co mu pokazać — opisuje osobny tekst: jak sprzedać oprogramowanie konkurentowi.

Czego nie obiecywać: wyłączności bezterminowej, wyłączności każdemu, kto zapyta pierwszy, i ceny, która „nigdy się nie zmieni”. Pierwsza zamyka branżę, druga jest niewykonalna, trzecia wraca jako zarzut przy pierwszej podwyżce.

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

Umowa obiecuje dokładnie tyle, ile aplikacja potrafi wykonać. Zdanie „na żądanie wydamy komplet danych w czternaście dni” bez działającego eksportu jest obietnicą bez pokrycia, a to pierwszy zapis, który partner sprawdzi, kiedy zacznie się rozstawać.

Po Twojej stronie zostają decyzje handlowe: co sprzedajesz, komu i na jak długo, jaki jest próg wyłączności, kiedy i o ile zmienia się cena, która firma z branży wchodzi pierwsza i co obiecujesz na spotkaniu. Tego nikt nie zrobi za Ciebie, bo to Ty znasz rachunek tych firm.

Po stronie zespołu technicznego zostaje to, co czyni te zapisy wykonalnymi: oddzielenie danych każdej firmy na poziomie bazy, role i dziennik dostępu, eksport oraz usunięcie na żądanie, kopie zapasowe z testem odtworzenia, rozliczenia i utrzymanie po starcie.

U nas każda budowana aplikacja dostaje własny projekt bazy i własne konto rozliczeniowe, więc dane i pieniądze jednej firmy nie mieszają się z cudzymi, a wyjście partnera nie polega na wycinaniu jego wierszy ze wspólnej tabeli. Rolę operatora przypinamy do identyfikatora użytkownika, nie do adresu e-mail.

Zanim wpiszesz terminy do umowy, poproś zespół o pokazanie eksportu i usunięcia danych jednej firmy na środowisku testowym. Termin, którego nikt nie zmierzył, jest życzeniem, a partner sprawdzi go w najgorszym możliwym momencie.

Co z tego wynika dla samego zapisu procesu, od którego zaczyna się aplikacja, pokazuje tekst jak spisać swój proces dla całej branży; dlaczego masz już większość składników — znasz branżę od środka.