Telefon w piątek wieczorem.
- Klient z 60 mln PLN obrotu rocznego: “Chcę przenieść projekt do innej firmy”.
- Pierwsze pytanie: “Masz dostęp do repozytorium kodu?”.
- Odpowiedź: “Nie wiem. Chyba agencja ma”.
- Drugie: “A do serwera? Środowisk testowych?”.
- “Też chyba jest u nich”.
Sześć tygodni później transfer zamknął się fakturą 80 000 PLN za “awaryjne odzyskanie infrastruktury”. Większość klientów odkrywa to dopiero wtedy, kiedy chce odejść.
Ten wpis pokazuje 7 obszarów własności, które trzeba zapisać w umowie zanim podpiszesz, próbkę klauzuli “Własność infrastruktury” do skopiowania, i 3 scenariusze co robić jeśli już podpisałeś bez tych zapisów.
Sytuacja: sklep opłacony, ale infrastruktura nie Twoja
Wdrożenie skończone dwa lata temu. Faktury opłacone, sklep działa, klienci kupują. Po tych dwóch latach okazuje się, że ten sam zespół, który zbudował sklep, nie pracuje już tak jak na początku. Spada tempo, raportowanie się rozjeżdża, zmiany stoją w miejscu. Klient decyduje się na zmianę dostawcy. Logiczna decyzja biznesowa.
I tu zaczyna się prawdziwy projekt. Repozytorium z kodem siedzi na koncie GitHub założonym przez agencję. Hosting produkcyjny w AWS na koncie agencji - faktury idą do agencji, klient płaci agencji za “obsługę infrastruktury”. Domena owszem zarejestrowana na klienta, ale DNS przepięty na Cloudflare na koncie agencji.
Klient ma sklep, który działa i zarabia. Swojej infrastruktury jednak nie ma. Zmiana agencji e-commerce nie zaczyna się od podpisania umowy z nową firmą - zaczyna się od audytu tego, co naprawdę masz po stronie własnościowej. Bez tego audytu nowa agencja dostaje brief “przenieś sklep”, a po tygodniu wraca z pytaniem “do czego mamy się logować?”.
Mechanizm powstawania tej sytuacji jest często ten sam. W trakcie wdrożenia agencja zakłada konta na siebie, bo to szybsze. Setup AWS na koncie agencji = 15 minut. Tak samo GitHub i Cloudflare. Klient nie pyta, bo ktoś mówi “my to ogarniemy, nie martw się o techniczne sprawy”. Klient ma sto innych spraw - dostawa, marketing, sprzedaż - i odpuszcza.
Dwa lata później to “ogarniemy” zamienia się w 80 000 PLN i sześć tygodni walki.
Dlaczego tak się dzieje - mechanizm systemowy
Zanim wejdziemy w checklistę, jedna ważna rzecz. Tutaj nie ma złych intencji. Mechanizm, który dzisiaj opisuję, jest racjonalny po obu stronach w fazie początkowej. Po stronie agencji szybkość wdrażania wygrywa z formalizacją własności - klient płaci za sklep, który ma ruszyć w 4 miesiące, nie za “proces wprowadzania kont”. Po stronie klienta zaufanie do zespołu wygrywa z procesem weryfikacji - “skoro mają nam pomóc, niech ogarną też dostępy”.
To racjonalne działanie, które daje ryzykowny rezultat dopiero przy zakończeniu współpracy. I to jest problem strukturalny rynku, a nie konkretnej agencji. W trakcie projektu nikt nie liczy kosztów zakończenia współpracy, bo nikt go nie planuje. Po co planować rozwód, jak dopiero bierzesz ślub?
Polski rynek e-commerce w 2026 nie ma żadnego publicznego standardu jak ma wyglądać własność infrastruktury. Każda agencja robi to po swojemu. Każdy klient kupuje “wdrożenie sklepu” jakby to była jedna pozycja na fakturze. Tymczasem to jest 7 oddzielnych obszarów własności, z których każdy może być na koncie kogoś innego.
To nie kwestia złej woli tylko brak procesu po obu stronach. Naprawia się to dokumentem.
7 obszarów własności do zapisania w umowie
Schemat, który klient z dialogu na początku tego wpisu chciałby mieć w umowie przed podpisaniem. Teraz dorabiamy go odwrotnie - audyt tego, co jest, i plan transferu. Każdy z tych 7 obszarów to obowiązkowy zapis w umowie. Zmiana agencji e-commerce w przyszłości albo pierwsza umowa z nową agencją - te same 7 obszarów, ten sam mechanizm prewencji.
| Zasób | Właściciel | Read access | Write access |
|---|---|---|---|
| Repozytorium kodu | Klient (konto GitHub/GitLab) | Klient + Agencja (team member) | Klient (admin) + Agencja (write per branch) |
| Hosting produkcyjny | Klient (konto główne) | Klient + Agencja (ograniczony odczyt) | Klient (konto główne) + Agencja (klucze wdrożeniowe) |
| Środowiska stage/dev | Klient (konto podrzędne hostingu) | Klient + Agencja (pełny) | Agencja (wdrożenia) + Klient (odczyt do audytu) |
| Domeny i DNS | Klient (rejestrator + Cloudflare/Route53) | Klient + Agencja (odczyt) | Klient (admin) + Agencja (edycja rekordów DNS) |
| Integracje (Stripe/InPost/ERP) | Klient (konto sprzedawcy) | Klient + Agencja (rola użytkownika) | Klient (właściciel) + Agencja (rola per integracja) |
| Dane (CRM, ERP, baza klientów) | Klient (administrator danych GDPR) | Klient + Agencja (na bazie umowy) | Klient + Agencja (rejestrowany ślad audytowy) |
| Dokumentacja i know-how | Klient (wiki/repo dokumentacji) | Klient + Agencja | Agencja (zapis) + Klient (akceptacja) |
Każdy z tych obszarów powinien być częścią umowy zmiany agencji albo pierwszej umowy z nową agencją.
1Repozytorium kodu
GitHub, GitLab albo Bitbucket. Konto organizacyjne klienta, nie agencji. Agencja dostaje dostęp zespołowy na poziomie potrzebnym do pracy - z możliwością modyfikacji kodu, ale bez uprawnień administratora organizacji. Kopia zapasowa poza repo (kopia lustrzana na innym serwerze klienta, raz w tygodniu) na wypadek incydentu z platformą.
2Hosting i serwery produkcyjne
AWS, OVH, Hetzner, hosting tradycyjny - wszystko jedno. Główne konto na klienta, faktury idą do klienta. To jest najprostszy test własności w całym wpisie: spójrz na fakturę za hosting. Jeśli wystawiona na agencję - hosting jest agencji. Jeśli wystawiona na klienta - hosting jest klienta. Agencja dostaje dostęp przez klucz SSH albo dedykowane uprawnienia wdrożeniowe. Nie potrzebuje konta głównego. Jeśli ktoś po stronie agencji argumentuje “musimy mieć pełne uprawnienia, bo czasem trzeba szybko coś zmienić w nocy” - to znaczy że nie ma procesu wycofywania zmian i obsługi awarii, i to też jest osobny problem do rozwiązania. Główne konto agencji na produkcji = dźwignia agencji w trakcie zmiany dostawcy.
3Środowiska stage i dev
Stage i dev często idą na konto podrzędne hostingu klienta albo osobny poziom u tego samego dostawcy. Synchronizacja stage z produkcją (odświeżanie danych, spójność kodu) powinna być procesem, nie jednorazowym ustawieniem. Klient ma dostęp tylko do odczytu na stage żeby móc samodzielnie weryfikować wdrożenia przed go-live. Częsta pułapka: stage zarządzany przez agencję na ich subdomenie typu client-stage.agencja.pl. Brzmi niewinnie, ale to znaczy że nawet stage jest u nich. Po zakończeniu współpracy z agencją trzeba odtwarzać stage od zera. Lepsza praktyka: stage na subdomenie klienta stage.sklep.pl za basic auth.
4Domeny i DNS
Domena zarejestrowana bezpośrednio przez klienta u rejestratora (OVH, nazwa.pl, Cloudflare). Konto DNS na klienta. Agencja dostaje uprawnienia delegowane do edytowania rekordów DNS w trakcie wdrożeń, ale nie własności całej strefy. Email kontaktowy związany z domeną ustawiony na adresy klienta, nie agencji. Brzmi jak detal, ale przy sporze z agencją to często ten email decyduje kto otrzymuje powiadomienia z rejestratora przy wygaśnięciu domeny albo próbie transferu. Tracenie domeny w sporze z agencją to nieodwracalne ryzyko biznesowe.
5Konta integracji
Tu lista zaczyna się rozrastać i tu często coś się gubi. Płatności: Stripe, Przelewy24, PayU, Tpay - wszystkie założone bezpośrednio przez klienta z KYC na firmę. Agencja dostaje klucz dostępowy API z ograniczonymi uprawnieniami. Kurierzy: InPost, DPD, GLS, UPS - kontrakty na klienta, integracja przez API klienta. ERP: Comarch, Subiekt, SAP - licencja na klienta, integracja agencji jako user. Narzędzia marketingowe: Google Ads, Meta Business, Klaviyo, GetResponse - konta klienta, agencja jako manager.
6Dane (CRM, ERP, baza klientów)
GDPR mówi jasno: administrator danych to właściciel sklepu, nie agencja. Agencja jest podmiotem przetwarzającym. To znaczy, że klient musi mieć w każdej chwili prawo do pełnego eksportu danych razem ze schematem, nie tylko zrzutu bazy. Bo zrzut bazy bez schematu po roku jest nieczytelny dla nowej agencji.
7Dokumentacja i know-how
To obszar, który najtrudniej formalnie egzekwować, ale najmocniej boli przy transferze. README projektu z architekturą i zależnościami. Procedury operacyjne - co robić jak padnie integracja z kurierem, jak wycofać wdrożenie w praktyce, kto dzwoni do kogo o 2 w nocy. Dokumentacja API i niestandardowych integracji plus opis kluczowych decyzji projektowych (dlaczego wybrano X, jak działają niestandardowe rozwiązania) - bez tego nowa agencja musi odtwarzać każdą integrację z systemu produkcyjnego.
I najtrudniejsze: wiedza w głowach zespołu. Dlaczego ta klasa nazywa się tak dziwnie, dlaczego ten cron job chodzi co 17 minut a nie co 15, dlaczego promocja Black Friday wymaga ręcznego restartu cache’a. To wiedza która siedzi w głowach 2-3 ludzi po stronie agencji i nie zapisuje się sama. W umowie zapisać: minimum 8 godzin sesji "przekazanie wiedzy" z developerami agencji przed zakończeniem współpracy, nagrane na video, z transkrypcjami.
Już podpisałeś bez klauzul "Własność infrastruktury"?
Sprawdźmy umowę razem. Audyt Współpracy: od 3 900 PLN, 5 dni roboczych, analiza luk 7 obszarów + plan transferu jeśli będzie konieczny.
Sprawdź jak to działa →Co konkretnie napisać w umowie
Zanim zaczniemy: to jest przykład wzorcowy do dyskusji z prawnikiem, nie gotowy zapis prawniczy do skopiowania bez weryfikacji. Każda umowa ma swój kontekst, a sformułowania prawne muszą być dopasowane do reszty kontraktu. Konsultacja z prawnikiem specjalizującym się w IT/e-commerce zajmuje 2-4 i jest najtańszym ubezpieczeniem. Zmiana agencji e-commerce za 3 lata kosztuje wielokrotnie więcej - prewencja wygrywa.
Klauzula "Własność infrastruktury"
Próbka klauzuli do dyskusji z prawnikiem
§X. Własność infrastruktury technicznej
1. Wszystkie zasoby techniczne związane z realizacją Projektu (w szczególności: repozytoria kodu, konta hostingowe, domeny, konta integracji z systemami zewnętrznymi, dane produkcyjne) pozostają własnością Klienta od momentu ich uruchomienia, niezależnie od podmiotu dokonującego ich technicznego założenia.
2. Wykonawca zobowiązuje się do założenia każdego zasobu technicznego na koncie Klienta lub do niezwłocznego transferu własności na konto Klienta w terminie nie dłuższym niż 7 dni od uruchomienia danego zasobu.
3. Wykonawca zobowiązuje się do przekazania pełnej dokumentacji dostępów (lista zasobów + procedura odzyskania kontroli + dane kontaktowe rejestratorów i dostawców) w terminie 14 dni od:
a) zakończenia Umowy
b) wezwania przez Klienta w trybie pisemnym
4. W przypadku niewykonania zobowiązań z ust. 2-3 Klient ma prawo do naliczenia kary umownej w wysokości 1% wartości Umowy za każdy dzień zwłoki, oraz do dochodzenia odszkodowania przewyższającego wysokość kary umownej.
Wzorzec do konsultacji z prawnikiem IT/e-commerce, nie gotowy zapis do skopiowania bez weryfikacji.
Mechanizm tej klauzuli jest prosty: 7 dni na techniczne przekazanie każdego zasobu w trakcie projektu (nie na końcu), 14 dni na przekazanie dokumentacji po zakończeniu umowy, 1% za każdy dzień zwłoki jako finansowy motywator. Bez kary umownej klauzula jest życzeniowa.
Załącznik "Tabela własności"
Tabela 7 obszarów własności (ta sama z sekcji wyżej) jako załącznik do umowy z polem "deadline transferu" wypełnionym konkretnymi datami przez Wykonawcę. Załącznik podpisany razem z umową, aktualizowany po każdym sprincie jako "stan obecny". Bez tego załącznika klauzula §X jest abstraktem - z nim staje się egzekwowalnym dokumentem operacyjnym.
Co jeśli już podpisałeś bez tych klauzul
Zmiana agencji e-commerce bez przygotowanej umowy ma 3 scenariusze, zależnie od jakości relacji z obecną agencją.
Scenariusz A: agencja chętnie współpracuje
Najczęstszy przypadek, jeśli relacja była rzetelna. Wysyłasz formalny wniosek transferu z listą 7 obszarów. Agencja w odpowiedzi przygotowuje plan przekazania - eksport repozytorium, transfer własności kont hostingu, sesje przekazania wiedzy. Potwierdzasz akceptację po każdym obszarze.
Czas: 2-4 tygodnie standardowo. Koszt: 5 000-15 000 PLN za czas pracy zespołu agencji nad transferem (sensowne, sami to robili dla swoich klientów). Ryzyko niskie. Wszyscy chcą żeby to się skończyło dobrze.
Scenariusz B: agencja stawia opór
Tu wracamy do case’a z początku wpisu. 60 mln PLN obrotu rocznego, agencja słyszy słowo “transfer” i nagle:
Agencja: “Dedykowane moduły to nasza własność intelektualna, do tego potrzebny aneks i osobne wynagrodzenie”.
Klient: “Ale to mój kod, ja to opłaciłem”.
Agencja: “W umowie nie ma rozdziału o własności kodu po zakończeniu współpracy”.
Umowa milczała na ten temat. Sześć tygodni eskalacji, prawnicy po obu stronach, ostatecznie ugoda przy 80 000 PLN za “awaryjny transfer infrastruktury i przekazanie dokumentacji”. 13% wartości projektu poszło na coś, czego nie powinno być w ogóle. Konta na agencji + brak klauzul w umowie = dźwignia w negocjacjach.
W tym scenariuszu działania: prawnik IT specjalizujący się w sporach z agencjami (od dnia 1, nie po 3 tygodniach), formalny mail z wezwaniem do współpracy, screenshotty wszystkich komunikatów. Jeśli umowa milczy o własności - przygotuj się na ugodę, bo postępowanie sądowe trwa 18-36 miesięcy i kosztuje więcej niż transfer.
Scenariusz C: agencja nieosiągalna
Najgorszy scenariusz. Agencja zlikwidowana, główny zespół rozszedł się po rynku, nikt nie odpisuje na maile. To się zdarza częściej niż myślisz - polski rynek agencji e-commerce zna upadłości, zmiany właścicieli, pivoty na inne usługi.
Działania w tym scenariuszu: rejestracja domeny od nowa jeśli straciłeś dostęp do rejestratora (kosztuje drobne, ale jeśli ktoś przejmie domenę po wygaśnięciu, ratunek może kosztować setki tysięcy). Rekonstrukcja kodu z kopii zapasowej serwera produkcyjnego (jeśli masz dostęp do hostingu) albo z kodu wdrożonego na produkcji (odtwarzanie przez analizę, kosztowne). Dane klientów z eksportów GDPR, jeśli były regularne (jeśli nie - bezpowrotnie stracone).
Czas: 8-16 tygodni przy dobrych wiatrach. Koszt: zależy od skali, ale niektóre rzeczy są bezpowrotne stracone (wiedza nieformalna, historia decyzji architektonicznych). Lekcja na przyszłość: własna kopia zapasowa raz w kwartale, nawet jeśli relacja z agencją wygląda dobrze. Firmy upadają bez ostrzeżenia.
Checklista Dostępów - 21 punktów do weryfikacji w umowie
Pełna lista wszystkich 7 obszarów własności z 21 konkretnymi punktami do sprawdzenia w obecnej lub przyszłej umowie z agencją. Część Toolkitu E-Commerce na Jamnika. Zostaw email, dam znać jak będzie gotowe.
Dołącz do listy oczekujących →FAQ
Czy mogę renegocjować dostępy w trakcie współpracy z obecną agencją?
Tak, i to jest często lepsza droga niż czekanie do zakończenia umowy. Wystarczy aneks do umowy z klauzulą "Własność infrastruktury" + tabelą 7 obszarów. Najlepszy moment na renegocjację to dorzucenie większej zmiany w zakresie - agencja i tak otwiera kontrakt, można dorzucić aneks o własności bez psucia relacji. Zmiana agencji e-commerce nie wymaga zerwania umowy - można negocjować dostępy w trakcie i mieć je transferowane sprintem.
Argument do agencji: "Chcemy zapisać formalnie to, co i tak nieformalnie działa, żeby zabezpieczyć obie strony przy ewentualnej zmianie zespołu po waszej stronie albo zmianie struktury firmy po naszej". Rzadko spotyka się opór - racjonalne agencje rozumieją, że to standardowa praktyka.
Co jeśli agencja twierdzi, że custom moduły to ich IP?
Częsta sytuacja. Rozróżnienie wygląda tak: kod custom napisany dla Twojego projektu (Twoja specyfikacja, Twoje pieniądze) = Twoje IP, chyba że umowa wprost mówi inaczej. Framework agencji używany w wielu projektach (ich know-how) = ich IP, używasz na licencji.
W umowie powinno być zapisane wprost: "wszystkie wyniki prac stworzone dla Klienta w ramach Projektu (kod, konfiguracje, dokumentacja) stanowią własność Klienta. Biblioteki i frameworki Wykonawcy używane w Projekcie są używane przez Klienta na podstawie licencji". Bez tego rozróżnienia agencja może próbować zatrzymać "swój framework" razem z Twoim custom kodem.
Ile kosztuje Audyt Współpracy i co zawiera?
Audyt Współpracy kosztuje od 3 900 PLN netto, 5 dni roboczych. Zawiera: analiza luk obecnej umowy w 7 obszarach własności (co jest zapisane, co milczy, co jest ryzykowne), audyt rzeczywistego stanu dostępów (kto faktycznie ma pełną kontrolę nad 7 obszarami - często rozjazd z umową), plan transferu jeśli będzie konieczny (z estymacją czasu i kosztu per scenariusz A/B/C), oraz pisemne rekomendacje aneksu do umowy jeśli aktualnie nie planujesz rozstania, ale chcesz się zabezpieczyć.
Audyt Współpracy obejmuje 7 obszarów własności w pełnej analizie i daje Ci ocenę gotowości - zmiana agencji e-commerce za rok albo za 5 lat staje się wtedy decyzją taktyczną, nie awaryjną. Rzecz, której dowiadujesz się w 5 dni za 3 900 PLN, najczęściej kosztowałaby Cię dziesiątki tysięcy PLN przy rzeczywistym transferze.
Czy konieczny prawnik przy klauzulach umowy?
Dla próbek klauzul z tego wpisu - TAK, finalna wersja powinna być zweryfikowana przez prawnika specjalizującego się w IT lub e-commerce. Koszt kilku godzin pracy prawnika to kilka tysięcy PLN, niewspółmierne do ryzyka źle sformułowanej klauzuli. Dla samego audytu rzeczywistych dostępów (kto faktycznie ma pełną kontrolę) prawnik NIE jest konieczny - to praca techniczna, którą robi konsultant e-commerce lub Twój zespół wewnętrzny.
Strategia hybrydowa: konsultant audytuje stan obecny + proponuje aneks, prawnik formalizuje treść aneksu. Łączny koszt zwykle 8 000-15 000 PLN, niewspółmierne do potencjalnego sporu 80 000 PLN+ przy późniejszym rozstaniu.
Następny krok
Zmiana agencji e-commerce ma 3 dobre wejścia, zależnie od momentu, w którym jesteś.
Jeśli dopiero porównujesz oferty na pierwsze wdrożenie i nie wiesz która ma sens - zobacz porównanie ofert wdrożenia e-commerce 180k vs 450k.
Jeśli Twoje wdrożenie ma rozmiar 5-15 mln PLN i potrzebujesz stałego nadzoru przez cały cykl - nadzór wdrożenia e-commerce dla sklepu 5-15 mln PLN.
