Po wdrożeniu strona internetowa jest realnie pod kontrolą firmy dopiero wtedy, gdy wynika to z umowy, dostępu do kont i przekazanych materiałów. Sam fakt, że strona działa pod właściwym adresem, nie oznacza jeszcze, że firma może ją swobodnie przenieść, rozwijać, przekazać innemu wykonawcy albo modyfikować wszystkie jej elementy.
Najbezpieczniej ustalić te sprawy wcześniej, bo decyzje przed zleceniem strony często przesądzają, czy po publikacji masz narzędzie firmy, czy projekt zależny od jednej osoby. Własna strona internetowa to nie tylko wygląd i adres. To także prawa lub licencja, domena, hosting, CMS, kod, treści, grafiki, backup i konta wokół strony.
Najkrótsza odpowiedź brzmi więc: nie pytaj tylko "kto jest właścicielem strony?", ale "co dokładnie jest pod moją kontrolą?". Inaczej można mieć opłaconą stronę, a jednocześnie nie mieć dostępu administracyjnego, nie znać abonenta domeny, nie mieć kopii zapasowej, nie wiedzieć, czy wolno modyfikować grafiki, albo nie móc przenieść projektu do innego wykonawcy.
Werdykt w 30 sekund
- Masz realną kontrolę, jeśli umowa określa prawa lub licencję, firma ma konto administratora CMS, kontrolę nad domeną i hostingiem, backup, dostęp do kont oraz jasny opis tego, co wolno modyfikować.
- Doprecyzuj przed odbiorem, jeśli brakuje informacji o licencji fontu, źródle grafik, odbiorcach formularzy, procedurze przekazania haseł albo zasadach odnowienia domeny i hostingu.
- Wstrzymaj odbiór, jeśli domena lub hosting są na prywatnym koncie wykonawcy bez zasad przeniesienia, masz tylko konto redaktora w CMS, nie ma backupu albo nie wiadomo, kto ma prawa do kodu i materiałów.
- Nie traktuj tego jak porady prawnej: przy sporze, dużym projekcie, niejasnym przeniesieniu praw albo elementach stockowych, AI, open source i autorskich warto sprawdzić umowę z prawnikiem.
Czy po wdrożeniu strona jest Twoja w 30 sekund
Strona internetowa składa się z kilku warstw. Każda może mieć innego "właściciela" w praktycznym sensie: ktoś inny może być abonentem domeny, ktoś inny płatnikiem hostingu, ktoś inny administratorem CMS, a jeszcze inne zasady mogą dotyczyć kodu, zdjęć, fontów i wtyczek.
Dlatego przy odbiorze nie wystarczy zdanie "strona należy do klienta". Trzeba sprawdzić, co to oznacza w dokumentach i panelach.
| Warstwa strony | Co oznacza realna kontrola | Co powinno istnieć jako dowód |
|---|---|---|
| Umowa i prawa | Wiesz, czy masz przeniesienie praw, licencję i zgodę na modyfikacje | Umowa, protokół odbioru, załącznik z zakresem praw lub licencji |
| Domena | Firma jest abonentem albo ma jasno opisany sposób przejęcia domeny | Panel rejestratora, dane abonenta, zasady odnowienia i transferu |
| Hosting | Wiesz, gdzie działa strona, kto opłaca usługę i kto reaguje na awarię | Panel hostingu, dane płatnika, zakres opieki, backup |
| CMS | Firma ma właściwą rolę, najlepiej administratora lub właściciela | Konto administracyjne, lista użytkowników i uprawnień |
| Kod i repozytorium | Da się rozwijać projekt albo przekazać go innemu wykonawcy | Repozytorium, pliki projektu, opis wdrożenia, zależności |
| Treści i grafiki | Wiesz, kto dostarczył materiały i na jakich zasadach można ich używać | Licencje, zgody, źródła plików, informacja o plikach źródłowych |
| Konta i dane | Dane pomiarowe, formularze i integracje zostają pod kontrolą firmy | Dostęp właścicielski do kont, lista integracji, role użytkowników |
Jeśli któraś z tych warstw jest niejasna, nie oznacza to automatycznie konfliktu. Oznacza natomiast, że przed podpisaniem odbioru trzeba doprecyzować zakres. Najgorzej działa sytuacja, w której klient akceptuje projekt, bo "wszystko się otwiera", a dopiero po kilku miesiącach odkrywa, że nie może zmienić wykonawcy, przenieść hostingu albo odzyskać dostępu do kont.
Czerwona flaga: strona działa publicznie, ale wykonawca nie przekazał listy dostępów, nie wskazał abonenta domeny, nie opisał praw do materiałów i nie wyjaśnił, co stanie się po zakończeniu współpracy. To nie jest bezpiecznie domknięte wdrożenie.
Umowa: co decyduje o prawach do strony
O prawach do strony nie decyduje sam wygląd serwisu ani sama płatność faktury. Decydują ustalenia w umowie, licencje oraz to, co faktycznie zostało przekazane. W praktyce warto rozdzielić kilka elementów: projekt graficzny, kod, teksty, zdjęcia, ikony, fonty, motywy, wtyczki, konfigurację CMS i materiały zewnętrzne.
Nie trzeba używać języka prawniczego w codziennej rozmowie z wykonawcą, ale w dokumencie powinno być jasne, czy klient dostaje przeniesienie autorskich praw majątkowych, licencję, czy tylko prawo korzystania z gotowej strony w określonym zakresie. Jeżeli umowa mówi o przeniesieniu praw, powinna wskazywać, czego ono dotyczy i na jakich polach eksploatacji. Jeżeli mowa o licencji, trzeba wiedzieć, czy pozwala na modyfikacje, utrzymanie, przeniesienie i dalszy rozwój strony.
| Element | Co sprawdzić w umowie | Dlaczego to ważne |
|---|---|---|
| Projekt strony | Czy można go używać, modyfikować i rozwijać po odbiorze | Bez tego zmiana layoutu może wymagać dodatkowej zgody albo nowej wyceny |
| Kod | Czy klient otrzymuje kod, repozytorium lub licencję na korzystanie | Bez kodu trudniej zmienić wykonawcę przy projekcie custom |
| Treści | Kto pisze teksty i kto ma do nich prawa po akceptacji | Teksty mogą być później przenoszone, edytowane i wykorzystywane w kampaniach |
| Grafiki i zdjęcia | Czy są autorskie, stockowe, dostarczone przez klienta czy zewnętrzne | Każdy wariant może mieć inne zasady użycia i modyfikacji |
| Fonty, wtyczki, szablony | Czy licencje pozwalają na użycie komercyjne i dalsze utrzymanie | Strona może działać, ale jej elementy nadal podlegają licencjom dostawców |
| Pliki źródłowe | Czy klient dostaje tylko gotową stronę, czy także pliki robocze | Pliki źródłowe logo, grafik lub makiet nie zawsze są domyślnie w cenie |
Sformułowanie "wykonanie strony internetowej" jest zbyt ogólne, jeśli projekt ma być rozwijany. Może oznaczać samo wdrożenie serwisu, ale nie musi automatycznie wyjaśniać, czy klient może przenieść kod, tworzyć wersje językowe, przebudować podstrony, użyć grafik w reklamie albo przekazać repozytorium kolejnemu programiście.
Warto też odróżnić błąd od nowego zakresu. Jeżeli formularz nie działa tak, jak ustalono, to zwykle jest temat do poprawki. Jeżeli po odbiorze klient chce dodać moduł rezerwacji, nową integrację albo całkowicie zmienić zaakceptowany układ, to może być już nowe zlecenie. Umowa i protokół odbioru powinny pomagać odróżnić te sytuacje, a nie zostawiać je do negocjacji po fakcie.
Praktyczny wniosek: zanim uznasz, że masz własną stronę internetową, sprawdź nie tylko, czy ją opłaciłeś, ale też co wolno Ci z nią zrobić po wdrożeniu. Jeśli dokumenty nie rozróżniają kodu, projektu, treści, grafik, licencji i dostępu, poproś o doprecyzowanie.
Domena i hosting: kto ma techniczną kontrolę
Domena nie jest stroną, a hosting nie jest prawem do projektu. To osobne warstwy, które decydują o tym, czy użytkownik w ogóle trafi na serwis i czy firma może utrzymać go online. Przy domenach .pl bezpieczniej mówić o abonencie domeny, rejestratorze, panelu, DNS, odnowieniu i możliwości transferu, a nie o "kupieniu domeny na zawsze".
Firma może mieć prawa do projektu strony, ale stracić kontrolę operacyjną, jeśli domena została założona na prywatny adres wykonawcy, hosting jest w jego panelu, a przy domenie klient nie zna zasad cesji domeny lub zmiany operatora. Taki układ może działać miesiącami, dopóki współpraca jest dobra. Problem zaczyna się przy zmianie wykonawcy, awarii, sporze, końcu opieki albo konieczności przeniesienia poczty.
| Obszar | Co ustalić po wdrożeniu | Czerwona flaga |
|---|---|---|
| Abonent domeny | Na kogo zarejestrowana jest domena i kto może potwierdzać zmiany | Domena jest na osobę prywatną wykonawcy bez zasad cesji lub przeniesienia |
| Rejestrator i panel | Gdzie zarządza się domeną i kto ma dostęp do panelu | Klient zna adres strony, ale nie wie, gdzie odnawia domenę |
| DNS | Kto zarządza rekordami i kto może podpiąć stronę, pocztę lub subdomeny | Każda zmiana DNS wymaga proszenia byłego wykonawcy |
| Transfer lub AuthInfo | Jak zmienić operatora obsługującego domenę, jeśli będzie taka potrzeba | Wykonawca nie chce wyjaśnić procedury przeniesienia domeny |
| Hosting | Gdzie działa strona, kto opłaca usługę i kto ma dostęp administracyjny | Hosting jest w jednym pakiecie wykonawcy bez opisu wyjścia |
| Poczta | Czy publikacja strony nie narusza skrzynek i rekordów mailowych | Po zmianie strony nikt nie wie, kto odpowiada za pocztę |
| SSL i backupy | Czy strona działa po HTTPS i czy są kopie zapasowe | Backup "jest automatyczny", ale nikt nie wie gdzie i jak go odtworzyć |
Model, w którym wykonawca utrzymuje domenę i hosting w ramach opieki, nie musi być zły. Może być wygodny, jeśli firma nie chce zajmować się techniką. Musi jednak być opisany. Klient powinien wiedzieć, co jest w opiece, kto reaguje na awarie, jak wygląda wypowiedzenie, jak przenieść stronę i domenę, kto ma backup oraz co dzieje się z kontami po zakończeniu współpracy.
Szczególnie ważna jest poczta w domenie. Przy publikacji strony łatwo zmienić DNS tak, że strona zaczyna działać, ale skrzynki firmowe przestają odbierać wiadomości albo tracą poprawną autoryzację wysyłki. To nie jest detal techniczny. Dla firmy może to oznaczać utratę zapytań, faktur i korespondencji.
Decyzja: zaakceptuj model opieki wykonawcy tylko wtedy, gdy masz zapisane zasady dostępu, eksportu, przeniesienia, wypowiedzenia i odpowiedzialności za awarie. Jeśli firma nie wie, gdzie jest domena i hosting, nie ma jeszcze pełnej kontroli nad stroną.
CMS, kod i repozytorium: czy stronę da się rozwijać
Dostęp do CMS nie zawsze oznacza pełną kontrolę nad stroną. Konto redaktora pozwala zwykle zmienić treść, dodać wpis lub podmienić zdjęcie, ale nie musi pozwalać zarządzać użytkownikami, wtyczkami, ustawieniami formularzy, integracjami, kopią zapasową albo eksportem danych. Dlatego przy odbiorze trzeba zapytać nie tylko "czy mam login?", ale "jakie mam uprawnienia?".
Przy prostej stronie opartej na gotowym CMS konto administratora, instrukcja obsługi, backup i jasne ograniczenia edycji mogą wystarczyć. Przy projekcie custom, integracjach, własnych komponentach albo planowanym rozwoju przez innego wykonawcę ważniejsze staje się repozytorium, opis wdrożenia i lista zależności.
| Scenariusz | Co zwykle wystarczy | Kiedy dopytać mocniej |
|---|---|---|
| Prosta strona firmowa w CMS | Konto administratora, instrukcja, backup, lista wtyczek i motywów | Gdy klient ma tylko rolę redaktora albo nie może zarządzać użytkownikami |
| Strona na kreatorze lub SaaS | Konto właścicielskie, zasady eksportu, informacja o ograniczeniach platformy | Gdy strona działa tylko w abonamencie wykonawcy i nie wiadomo, jak odejść |
| Strona z kodem custom | Repozytorium, opis deployu, zależności, środowiska i dostęp do hostingu | Gdy "wszystko jest na serwerze", ale nikt nie umie odtworzyć projektu |
| Strona z integracjami | Dostępy do API, opis połączeń, konta usług zewnętrznych, logika formularzy | Gdy formularze działają, ale tylko wykonawca wie, dokąd trafiają dane |
| Sklep lub katalog | Role administracyjne, eksport produktów, dostęp do zamówień i ustawień | Gdy klient może edytować produkty, ale nie ma kontroli nad płatnościami lub wysyłką |
Repozytorium nie jest potrzebne w każdym projekcie w tym samym stopniu. Nie każda firma musi codziennie zaglądać do kodu. Chodzi o możliwość utrzymania i rozwoju. Jeśli za rok strona ma dostać nowy moduł, integrację z CRM albo zmianę wykonawcy, brak repozytorium i dokumentacji technicznej może znacząco utrudnić pracę.
Warto poprosić wykonawcę o prostą informację: co jest edytowalne w CMS, co wymaga pracy technicznej, czego nie da się zmienić bez przebudowy i które elementy zależą od licencji zewnętrznych. To ogranicza fałszywe oczekiwanie, że "mam panel, więc mogę zmienić wszystko".
Czerwona flaga: klient ma login do CMS, ale nie może dodać administratora, zmienić ustawień formularza, wykonać eksportu, sprawdzić backupu ani odebrać dostępu wykonawcy. To nie jest pełna kontrola, tylko ograniczony dostęp operacyjny.
Treści, grafiki i materiały zewnętrzne
Strona składa się nie tylko z kodu. Są na niej teksty, zdjęcia, ikony, grafiki, fonty, pliki do pobrania, szablony, motywy, wtyczki, biblioteki, czasem także materiały wygenerowane lub kupione od zewnętrznych dostawców. Każdy z tych elementów może mieć inne zasady użycia.
To ważne, bo klient często pyta: "czy mogę użyć tej grafiki w reklamie?", "czy mogę przenieść zdjęcia na nową stronę?", "czy mogę przekazać projekt innemu wykonawcy?", "czy dostanę pliki źródłowe?". Odpowiedź nie powinna wynikać z domysłu. Powinna wynikać z umowy, licencji albo informacji od wykonawcy.
| Materiał | Pytanie kontrolne | Co może pójść źle |
|---|---|---|
| Teksty | Kto je napisał i czy można je dalej edytować oraz przenosić | Treści są poprawne na stronie, ale brak jasności, czy można użyć ich w innych kanałach |
| Zdjęcia stockowe | Kto kupił licencję i na jakich warunkach | Zdjęcie działa na stronie, ale nie wolno użyć go w reklamie albo druku |
| Zdjęcia klienta | Czy klient ma zgodę na ich użycie i ewentualne publikacje osób lub obiektów | Materiał pochodzi z firmy, ale nie ma potwierdzenia prawa do publikacji |
| Ikony i grafiki | Czy są autorskie, z biblioteki, stockowe czy częścią szablonu | Nie wiadomo, czy można je przerobić lub przenieść do innego projektu |
| Fonty | Czy licencja obejmuje użycie na stronie i ewentualnie w materiałach marki | Strona korzysta z fontu, którego nie wolno użyć poza danym zakresem |
| Motywy i wtyczki | Kto ma konto, licencję i prawo do aktualizacji | Aktualizacje przestają działać po zakończeniu współpracy |
| Pliki źródłowe | Czy klient otrzymuje edytowalne pliki robocze, czy tylko gotowy efekt | Firma ma stronę, ale nie ma materiałów do dalszej pracy graficznej |
Pliki źródłowe grafik, makiet czy komponentów nie muszą być automatycznie tym samym co gotowa strona. Jeżeli mają być przekazane, warto wpisać to do zakresu. Podobnie z materiałami AI, stockami i bibliotekami open source: nie trzeba straszyć nimi czytelnika, ale trzeba wiedzieć, jakie są warunki użycia i kto odpowiada za ich zgodność z projektem.
Najbardziej ryzykowny jest model "materiały są skądś z internetu". Jeśli wykonawca nie potrafi wskazać źródła zdjęć, ikon, fontów lub szablonu, klient nie wie, czy może używać strony komercyjnie bez dodatkowego ryzyka. Przy poważniejszych projektach taki punkt warto wyjaśnić pisemnie, a nie w rozmowie.
Praktyczny wniosek: poproś o listę materiałów zewnętrznych i licencji. Nie musi to być rozbudowany dokument prawny. Wystarczy tabela: element, źródło, kto ma licencję, gdzie można używać, czy wolno modyfikować i czy można przenieść na inny serwer lub do innego systemu.
Konta i dane po wdrożeniu
Własna strona internetowa to także konta, które działają wokół niej. Nawet jeśli sama witryna jest poprawnie wdrożona, firma może stracić kontrolę nad danymi, jeśli analityka, formularze, mapa, CRM, newsletter albo konta reklamowe są założone na prywatny adres wykonawcy.
Przy odbiorze warto przygotować jedną listę kont. Nie chodzi o wysyłanie haseł w mailu. Chodzi o to, żeby wiedzieć, gdzie istnieją konta, kto jest właścicielem, jakie role mają użytkownicy i co trzeba odebrać wykonawcy po zakończeniu prac.
| Konto lub narzędzie | Co powinno być pod kontrolą firmy | Pytanie przy odbiorze |
|---|---|---|
| Analityka | Właścicielskie konto firmy i dostęp do historii danych | Czy konto jest firmowe, czy prywatne wykonawcy? |
| Search Console | Dostęp właściciela lub pełne uprawnienia | Kto może zweryfikować domenę i dodać kolejnego użytkownika? |
| Formularze | Odbiorcy wiadomości, zgody, antyspam, integracje | Dokąd trafiają zapytania i kto może zmienić ustawienia? |
| Newsletter lub CRM | Konto firmy, baza kontaktów, zgody i eksport danych | Czy dane można wyeksportować po zakończeniu współpracy? |
| Profil Firmy i mapy | Właściciel konta oraz role osób obsługujących | Czy wykonawca jest tylko menedżerem, czy właścicielem profilu? |
| Konta reklamowe | Dostęp do kampanii, pikseli, konwersji i danych | Czy firma zachowuje historię kampanii i ustawienia pomiaru? |
| Integracje API | Klucze, tokeny, konta usług, odpowiedzialność za odnowienia | Kto może odwołać dostęp i wygenerować nowe klucze? |
Po odbiorze warto ograniczyć dostęp wykonawcy do tego, co jest potrzebne do opieki lub gwarancji. To nie jest brak zaufania, tylko normalne porządkowanie odpowiedzialności. W praktyce oznacza to osobne konta użytkowników, role zamiast wspólnego loginu, włączone 2FA tam, gdzie to możliwe, i listę aktywnych dostępów.
Najgorszy wariant to jedno wspólne konto "admin", którym posługują się klient, wykonawca, copywriter i osoba od reklam. Przy błędzie, wycieku lub przypadkowej zmianie nie wiadomo wtedy, kto co zrobił. Przy odejściu jednej osoby trzeba zmieniać hasła wszystkim, a czasem nie wiadomo nawet, ile kopii loginu krąży poza firmą.
Czerwona flaga: dane z formularzy, analityka lub konta reklamowe są podpięte do prywatnego maila wykonawcy i nie ma jasnej procedury przekazania właścicielstwa. Strona może działać, ale firma nie kontroluje danych, które pomagają ocenić jej skuteczność.
Kiedy opieka wykonawcy ma sens, a kiedy blokuje firmę
Nie każda firma chce samodzielnie zarządzać hostingiem, aktualizacjami, kopiami zapasowymi i technicznymi zgłoszeniami. Opieka wykonawcy może być dobrym rozwiązaniem, jeśli jest jasno opisana. Problem zaczyna się wtedy, gdy opieka techniczna zastępuje przekazanie kontroli.
Zdrowy model opieki odpowiada na kilka pytań: co jest w pakiecie, kto odpowiada za awarie, jak często powstają backupy, jak zgłasza się błędy, ile trwa wypowiedzenie, jak wygląda eksport danych i co firma otrzymuje przy zakończeniu współpracy. Bez tego opieka może wyglądać wygodnie tylko do pierwszego sporu albo pilnej migracji.
| Model | Kiedy jest w porządku | Kiedy uważać |
|---|---|---|
| Klient ma pełną kontrolę, wykonawca ma dostęp techniczny | Firma jest właścicielem kont, a wykonawca działa w roli administratora lub opiekuna | Jeśli wykonawca używa jednego wspólnego loginu zamiast osobnego konta |
| Wykonawca utrzymuje stronę w swoim środowisku | Jest umowa opieki, SLA lub zasady reakcji, backup i procedura wyjścia | Jeśli klient nie wie, jak odzyskać stronę i domenę po wypowiedzeniu |
| Strona działa na SaaS lub kreatorze | Firma ma konto właścicielskie i zna ograniczenia platformy | Jeśli projekt jest technicznie nieprzenoszalny, a nikt tego wcześniej nie powiedział |
| Wykonawca obsługuje wszystko kompleksowo | Firma dostaje raport dostępu, kopie, jasny zakres i prawo do przeniesienia | Jeśli "kompleksowo" oznacza brak paneli, brak dokumentacji i brak eksportu |
Nie ma jednej uniwersalnej długości gwarancji, jednego czasu reakcji ani jednej ceny opieki, które pasują do każdego projektu. Te wartości powinny wynikać z oferty, umowy albo regulaminu współpracy. Ważne jest nie to, żeby klient znał każdy techniczny szczegół, tylko żeby nie był zakładnikiem nieopisanej usługi.
Decyzja: opieka wykonawcy jest dobrym rozwiązaniem, gdy firma wie, co dostaje, jak odzyskać dane i jak zakończyć współpracę bez utraty strony. Jest ryzykowna, gdy zastępuje umowę, dostęp, backup i procedurę przeniesienia.
Checklista odbioru: odbierz, doprecyzuj albo wstrzymaj
Odbiór strony nie powinien kończyć się wyłącznie akceptacją wyglądu. To moment, w którym trzeba sprawdzić, czy firma może utrzymać, przenieść i rozwijać projekt. Najprościej przejść przez trzy decyzje: odbierz, doprecyzuj albo wstrzymaj.
| Element | Pytanie kontrolne | Decyzja |
|---|---|---|
| Umowa i prawa | Czy wiadomo, co klient może robić z projektem, kodem, treściami i grafikami? | Odbierz, jeśli zakres praw lub licencji jest jasny |
| Domena | Czy firma jest abonentem albo zna procedurę przejęcia i transferu? | Wstrzymaj, jeśli domena jest na prywatnym koncie bez zasad przeniesienia |
| Hosting | Czy wiadomo, gdzie działa strona, kto płaci i kto reaguje na awarie? | Doprecyzuj, jeśli brakuje zasad odnowienia lub wypowiedzenia |
| CMS | Czy firma ma konto administratora lub właściciela? | Wstrzymaj, jeśli ma tylko konto redaktora bez wyjaśnienia |
| Kod i repo | Czy przy projekcie custom jest repozytorium, opis wdrożenia i lista zależności? | Doprecyzuj lub wstrzymaj, jeśli strona ma być dalej rozwijana technicznie |
| Backup | Czy istnieje kopia startowa i wiadomo, jak ją odtworzyć? | Wstrzymaj, jeśli nie ma kopii ani procedury |
| Treści i grafiki | Czy znane są źródła materiałów i licencje? | Doprecyzuj, jeśli nie wiadomo, skąd pochodzą zdjęcia, fonty lub ikony |
| Konta i dane | Czy analityka, formularze, Search Console i integracje są pod kontrolą firmy? | Wstrzymaj przy kontach właścicielskich na prywatnym mailu wykonawcy |
| Opieka po starcie | Czy są zasady zgłoszeń, poprawek, awarii i przeniesienia? | Doprecyzuj, jeśli wsparcie jest tylko ustną deklaracją |
Krok po kroku można zrobić to tak:
- Zbierz umowę, ofertę, protokół odbioru i listę funkcji w jednym miejscu.
- Wypisz wszystkie konta: domena, hosting, CMS, analityka, formularze, poczta, CRM, newsletter, reklamy i integracje.
- Przy każdym koncie oznacz właściciela, administratora, płatnika i osoby z dostępem.
- Sprawdź, które materiały są autorskie, które dostarczył klient, a które pochodzą z licencji zewnętrznych.
- Poproś o backup startowy i opis odtworzenia strony po awarii.
- Przy projekcie custom poproś o repozytorium, opis deployu i listę zależności.
- Zapisz, co jest błędem do naprawy, co poprawką, a co nowym zakresem prac.
- Dopiero potem podpisz odbiór albo wróć z jedną uporządkowaną listą braków.
Blokerami odbioru są zwykle te elementy, które odbierają firmie kontrolę: brak jasnej umowy lub licencji, brak dostępu administracyjnego, brak kontroli nad domeną, brak backupu, brak zasad przeniesienia strony, brak informacji o materiałach zewnętrznych oraz konta firmowe założone wyłącznie na prywatny adres wykonawcy. Jeśli braki dotyczą dostępu, backupu, CMS lub instrukcji, porównaj protokół z tym, co powinien przekazać wykonawca po wdrożeniu strony.
Rzeczy do doprecyzowania to na przykład opis jednej roli w CMS, źródło konkretnego fontu, lista odbiorców formularza, tryb przekazania haseł, informacja o odnowieniu hostingu albo format zgłoszeń po starcie. Takie braki nie zawsze muszą blokować publikację, ale nie powinny zostać w pamięci jednej osoby.
Decyzja końcowa: własna strona internetowa po wdrożeniu to nie tylko serwis widoczny pod adresem. To możliwość utrzymania, przeniesienia, modyfikacji i rozwoju bez zgadywania, kto ma dostęp, kto ma prawa i kto odpowiada za kolejne działania. Jeśli te odpowiedzi są zapisane, odbiór ma sens. Jeśli nie, najpierw uporządkuj umowę, dostęp i pakiet przekazania.