Opieka techniczna WordPress w Rotterdamie

Polski zespół, który utrzymuje WordPressa dla firmy w Rotterdamie, nie dokłada „jeszcze jednego abonamentu aktualizacji”. Utrzymuje serwis, który stoi obok portu kontenerowego, kampusu Erasmus University Rotterdam (EUR) w Kop van Zuid, landingów firm logistycznych z integracją CRM, formularzy leadowych z polem KVK i witryn NL/EN, na rynku, gdzie martwy formularz albo regresja wersji holenderskiej w piątek przed Koningsdag to temat na rozmowę z compliance officerem i z działem operacyjnym, a nie tylko z marketingiem. Ta strona opisuje opiekę techniczną WordPressa właśnie w tym układzie: polski delivery, rotterdamski kontekst logistyki i B2B, bez cennika i bez obietnic dostępności w procentach.

Szerszy opis produktu opieki, niezależny od miasta, jest na stronie opieki technicznej WordPress. Tu schodzimy do Rotterdamu: port, Kop van Zuid, AVG z holenderską Autoriteit Persoonsgegevens (AP), pytanie o hosting w EOG, koordynacja freeze na Koningsdag i Black Friday oraz dziennik incydentów, który da się pokazać przy audycie. Sklep WooCommerce z checkoutem iDEAL to osobna ścieżka: programista WooCommerce w Rotterdamie. Budowa od zera albo przebudowa motywu idzie do programisty WordPress w Rotterdamie. Filary niezależne od miasta: programista WordPress i programista WooCommerce.

#Co oznacza opieka WordPress przy serwisie B2B, logistycznym albo korporacyjnym

Opieka to nie „włącz auto-update i miej nadzieję”. Dla strony korporacyjnej z Kop van Zuid, dostawcy IT z Rotterdam Science Tower, firmy logistycznej z Delfshaven albo serwisu NL/EN z integracją Mollie utrzymanie ma cztery twarde elementy: aktualizacje na kopii testowej, kopie zapasowe, które da się odtworzyć, WAF z sensownymi regułami oraz dziennik incydentów, który przeżyje pytanie audytora AP. Reszta - drobna zmiana w motywie, nowy formularz leadowy, poprawka Core Web Vitals na stronie z mapą biur - wisi na tym fundamencie. Bez niego kolejna wtyczka tylko powiększa powierzchnię ataku.

Serwis w Rotterdamie często zbiera dane, których nie wolno traktować jak treści bloga. Formularz zapytania B2B z numerem KVK, konto klienta z adresem dostawy w Beneluksie, zapis do newslettera po zgodzie cookie, panel partnera z danymi kontaktowymi, logowanie do strefy dystrybutora: każdy z tych ekranów po aktualizacji wtyczki potrafi się rozsypać ciszej niż strona główna. Dlatego regresja nie kończy się na „strona się ładuje”. Kończy się na ścieżce, którą kupujący, partner albo redaktor NL/EN naprawdę klika.

#Aktualizacje wyłącznie przez środowisko testowe

Rdzeń WordPress, wtyczki i motyw idą najpierw na środowisko testowe. środowisko testowe ma ten sam stos PHP, ten sam obiekt cache jeśli produkcja go ma, te same wtyczki formularzy albo integracji CRM w trybie sandbox. Aktualizacja „od razu na żywo, bo to tylko patch” jest najkrótszą drogą do martwego formularza leadowego w czwartek przed Koningsdag albo do integracji webhook, która przestaje zbierać dane w oknie kampanii Black Friday.

Po wgraniu łatek na kopii testowej idzie checklista, nie wyczucie. Logowanie wp-admin, zapis strony, formularz kontaktowy, integracja CRM, cron, poczta wychodząca, webhooki, purge cache po publikacji nowej oferty B2B, regresja wersji holenderskiej i angielskiej. Dopiero po tym produkcja. Ścieżka wycofania jest zapisana zanim ktokolwiek naciśnie deploy: która kopia, który tag, kto ma dostęp do hostingu. Jeśli tego nie ma na piśmie, to nie ma rollbacku, tylko improwizacja.

#Kopie operacyjne to nie archiwum compliance

Codzienna kopia WordPressa służy do odtworzenia serwisu po błędzie albo ataku. Archiwum compliance dotyczy czego innego: rejestrów przetwarzania, dowodów audytowych i możliwości wglądu organu nadzorczego. Kopia w panelu hostingu nie spełnia wymogów archiwum sama z siebie. Brakuje niezmienności, kompletności i dokumentacji procedury.

W praktyce utrzymania rozdzielamy trzy warstwy. Pierwsza: kopia operacyjna strony i bazy, z retencją zapisaną w runbooku, testem odtworzenia, nie tylko „backup job zielony”. Druga: logi zmian i incydentów, które pokazują kto, kiedy i co wgrał. Trzecia: archiwum compliance u klienta, zwykle w DMS albo u doradcy prawnego w Rotterdamie albo w Hadze. Trzymanie tych trzech warstw razem kończy się tym, że po dwóch latach nikt nie oddzieli tego, co trzeba przechować, od tego, co można usunąć.

#WAF, monitoring i dziennik pod audyt

WAF (mod_security, Cloudflare WAF albo reguły u hostera) odcina typowe skany i wstrzyknięcia, zanim dotrą do PHP. To nie zastępuje aktualizacji. To kupuje czas. Skan malware i kontrola integralności plików łapie to, co WAF przepuścił albo co weszło skradzionym hasłem. Dwuskładnikowe logowanie do wp-admin i ograniczenie liczby kont z uprawnieniem administratora są tańsze niż forensics po kradzieży sesji.

Dziennik incydentów jest równie ważny jak sama tama. Zapis: czas wykrycia, czas ograniczenia, czas przywrócenia, przyczyna, lista zmienionych plików i wtyczek, kto był powiadomiony. Dla właściciela firmy logistycznej z Kop van Zuid, operatora SaaS z Rotterdam Science Tower albo dyrektora IT z Delfshaven ten plik jest surowcem do zgłoszenia. Agencja WordPress nie składa raportu do AP za klienta. Dostarcza oś czasu, której klient nie musi rekonstruować z pamięci.

#Rotterdam jako kontekst, nie jako ozdobnik w tytule

Rotterdam to nie Amsterdam z fintechem przy Rokin ani Haga z instytucjami dyplomatycznymi. To drugie co do wielkości miasto Holandii, ośrodek logistyki morskiej, przemysłu i coraz gęstszego ekosystemu cyfrowego wokół Kop van Zuid, Rotterdam Science Tower i kampusów EUR. Tu serwis WordPress często obsługuje landingi produktowe B2B, formularze leadowe z integracją CRM, strony employer branding dla firm logistycznych i treści wielojęzyczne NL/EN, które muszą przeżyć aktualizację w tym samym tygodniu, w którym prawnik i tak pyta o AVG, hosting w EOG i cookie banner zgodny z holenderską interpretacją zgody.

#Port, Kop van Zuid i ekosystem logistyczno-cyberowy

Port Rotterdam i Kop van Zuid to punkty orientacyjne dla ekosystemu biznesowego w mieście: logistyka, przemysł, coraz więcej firm cyfrowych od D2C po SaaS. WordPress trzyma landingi produktowe, formularze demo, blogi techniczne i strony employer branding dla firm, które obsługują łańcuch dostaw albo infrastrukturę portową. Awaria po aktualizacji wtyczki formularza albo regresja w tłumaczeniach NL/EN boli w tygodniu kampanii rekrutacyjnej albo przed rozmową z inwestorem, nie w sierpniu.

Dla utrzymania wynika z tego prosta rzecz: aktualizacja wtyczki cache, integracji z HubSpot albo WPML musi przejść checklistę, która obejmuje formularz demo z polami KVK i panel partnera z mapą lokalizacji. środowisko testowe z tym samym stosem PHP i tymi samymi wtyczkami w sandbox to minimum, nie luksus. Dyrektor operacyjny z biura w Kop van Zuid nie akceptuje argumentu „strona główna działa”, kiedy formularz rejestracji zwraca 500 po aktualizacji wtyczki sesji.

Erasmus University Rotterdam i Hogeschool Rotterdam dostarczają ludzi, którzy umieją odróżnić motyw od wtyczki i wiedzą, że Polylang nie zastąpi procesu akceptacji EN. Pendlerzy z Den Haag, Delft, Schiedam i Vlaardingen pracują w jednym biurze po holendersku i po angielsku, więc strona NL/EN z polskim zapleczem redakcyjnym jest tu częstsza niż czysto polski front z holenderskim panelem.

#Koningsdag, Black Friday i koordynacja freeze

Koningsdag (27 kwietnia) i okres Black Friday to okna, w których firma w Rotterdamie nie toleruje eksperymentu na produkcji. Runbook freeze zapisuje: brak deployów od tygodnia przed eventem, aktualizacje krytyczne bezpieczeństwa tylko przez środowisko testowe i okno nocne, osobny przegląd cache i limitów PHP przed szczytem ruchu. Marketing zaplanował kampanię na piątek rano; developer, który robi „drobny patch cache” w czwartek wieczorem, uczy się kosztu na własnej skórze, kiedy formularz kontaktowy zwraca 500 przy pełnym ruchu.

To nie preferencja developera. To decyzja operacyjna uzgodniona z klientem przed sezonem. Ten sam schemat stosujemy przy wdrożeniach B2B, gdzie portal musi zostać dostępny w oknie zamówień tygodniowych. Kto robi „drobny patch integracji” w czwartek przed Black Friday, uczy się tego na własnej skórze, kiedy webhook CRM zwraca błąd przy pełnym ruchu z LinkedIn.

#Operacje specyficzne dla Holandii i EOG

Polski zespół zna WordPressa. Holenderski klient pyta o coś innego: gdzie leżą dane, czy serwer jest „w EOG”, jak długo trzymamy logi, kto jest administratorem danych, czy mamy Data Processing Agreement. Te pytania trzeba umieć obsłużyć procesem, nie sloganem o „zgodności z AVG”.

#AVG i holenderska AP

Holandia stosuje RODO jako AVG (Algemene verordening gegevensbescherming). Organ nadzorczy to Autoriteit Persoonsgegevens (AP). Dla WordPressa w Rotterdamie wynika z tego konkretny zakres utrzymania: lista podprocesorów (host, CDN, poczta, analityka, bramka płatności), umowa powierzenia tam, gdzie agencja przetwarza dane, procedura naruszenia w 72 godziny, minimalizacja danych w formularzach, privacybeleid zgodne z art. 13 AVG.

Utrzymanie nie zastępuje DPO klienta. Dostarcza logi, oś czasu i opis zmian po incydencie. Klient klasyfikuje, czy zdarzenie wymaga zgłoszenia do AP. Nikt po stronie agencji nie podpisuje się pod „jesteście zgodni z AVG, bo macie WAF”. To byłoby kłamstwo opakowane w produkt. AP publikuje wytyczne i narzędzia audytowe na autoriteitpersoonsgegevens.nl; runbook opieki powinien być z nimi zgodny co do tego, co agencja dokumentuje, a co zostaje po stronie administratora danych.

#Hosting w EOG

Dane osobowe pod AVG ciągną pytanie: w której jurysdykcji stoi serwer. AMS1 u TransIP w NL, AWS w Irlandii (eu-west-1), OVH we Francji, Hetzner w Niemczech to różne odpowiedzi dla compliance officer, ale wszystkie mieszczą się w EOG. Ashburn albo Oregon to Stany i zwykle veto bez Standard Contractual Clauses albo innej podstawy transferu.

Pytanie „czy hosting jest w Rotterdamie” wraca rzadziej niż „czy w EOG”. Odpowiedź operacyjna jest dwuczęściowa. Jurysdykcja: EOG, kopia nie wyjeżdża nocą na bucket w regionie US bez uzgodnienia. Latencja: origin w Holandii albo Irlandii plus CDN z terminałem TLS w EOG zwykle wystarcza dla użytkowników w Beneluksu i w Europie Środkowej. Rotterdam ma centra danych w aglomeracji, ale origin WordPressa nadal często stoi u dostawcy z regionem holenderskim albo irlandzkim. To nie jest wada. To jest jawna decyzja rezydencji, którą trzeba opisać w runbooku.

Rozmowa o hostingu w onboardingu jest więc merytoryczna, nie wizerunkowa. Czy produkcja jest w EOG? Czy kopia wyjeżdża? Czy CDN kończy TLS w uzgodnionej strefie? Czy obiekt cache nie trzyma prywatnej sesji ani nieopublikowanej oferty B2B? Utrzymanie, które „wrzuca wszystko na najtańszy VPS w USA”, nie przechodzi rozmowy z prawnikiem firmy z Kop van Zuid ani z dyrektorem operacyjnym przed Black Friday.

#Cookie banner, holenderska interpretacja zgody i oczekiwania rynku

Holenderski rynek jest wyczulony na cookie i tracking. AP wymaga świadomej zgody przed nieistotnymi plikami cookie. Wtyczki zgody (Complianz, Cookiebot, Iubenda) integrują się z GTM i Meta Pixel. Aktualizacja motywu albo wtyczki cache potrafi wyłączyć blokowanie skryptów do momentu, kiedy AP albo klient zauważy, że analityka leci przed zgodą. W opiece kwartalny przegląd bannera i tagów na kluczowych szablonach jest częścią runbooku, nie dodatkiem SEO.

#Redakcja dwujęzyczna NL/EN w utrzymaniu

Najczęstsze tarcie we współpracy Polska - Rotterdam nie jest w PHP. Jest w tonie i w parze języków. Holenderski UI strony firmowej używa formy grzecznościowej u. Angielska wersja nie może być dosłownym tłumaczeniem z polskiego briefu. Polylang i WPML rozwiązują hreflang i kopie językowe. Nie rozwiązują procesu: kto akceptuje holenderski tekst, kto angielski, zanim pójdzie na produkcję.

W opiece każda aktualizacja wtyczki wielojęzycznej przechodzi regresję obu wersji językowych na stagingu. Regresja „NL się zepsuło, bo ktoś edytował EN” wychodzi dopiero na porównaniu, nie w Lighthouse. Runbook zapisuje, czy akceptacja leży po stronie klienta w Rotterdamie, po stronie polskiego content leada, czy po obu równolegle. Polityka prywatności (privacybeleid) i cookie banner są szablonami z polami, nie blokami, które redaktor może przypadkiem usunąć z drzewa.

#Reakcja na incydent bez pustych procentów

Obietnica dostępności zapisana procentem na stronie city to ozdobnik, nie kontrakt. Dostępność wynika z hostingu, DNS, CDN, wtyczek i ludzi. Opieka opisuje procedurę, nie talizman.

Wykrycie: monitoring syntetyczny plus alert z WAF albo z hosta. Triage: czy to treść, czy formularz B2B, czy wp-admin, czy cała produkcja, czy wyciek oferty przed Koningsdag. Ograniczenie: tryb konserwacji, cofnięcie wtyczki, wyłączenie endpointu, rotacja haseł, twardy WAF, purge cache. Odtworzenie z kopii, jeśli pliki są spalone. Dokumentacja osi czasu. Post-mortem z przyczyną i z działaniem, które ma nie powtórzyć się za miesiąc.

Czas pierwszej odpowiedzi zapisujemy w umowie. W dniach roboczych priorytet zwykle zamyka się w oknie godzin, nie dni. Dyżur poza tym oknem jest wtedy, gdy umowa go obejmuje. Przy freeze Koningsdag albo Black Friday okno bywa szersze niż w zwykłym miesiącu, bo koszt martwego landingu w kwietniu albo listopadzie jest wyższy niż koszt dyżuru. Ta strona nie sprzedaje uniwersalnego SLA w tabelce. Sprzedaje porządek: widać, kto wszedł, co zmienił, kiedy serwis wrócił.

Jeśli klient musi złożyć zgłoszenie do AP albo do wewnętrznego audytu, dziennik z opieki jest załącznikiem. Brak dziennika oznacza, że compliance składa raport ze zrzutów ekranu i ze wspomnień z Slacka.

#Przypadek: aktualizacja cache położyłaby formularz przed kampanią, środowisko testowe to zatrzymał

Serwis korporacyjny na WordPressie, firma logistyczna z Kop van Zuid, ruch z LinkedIn i newslettera, piątek 10:00 start kampanii z formularzem leadowym. W kolejce do produkcji leżała aktualizacja wtyczki cache obiektowego plus patch SEO, „drobny, na żywo, bo to tylko Redis”.

Na środowisku testowym, sklonowanym z produkcji razem z Redisem, formularz kontaktowy po wysłaniu zwracał błąd 500. Przyczyna: zmiana klucza sesji po patchu cache, stary fragment motywu wołał $_SESSION przed inicjalizacją WordPressa, CDN trzymał HTML formularza bez rozróżnienia zalogowany/niezalogowany. Na produkcji ten sam zestaw poszedłby w czwartek wieczorem. Kampania wyszłaby o 10:00, setki leadów utknęłyby bez zapisu, support dostałby ticketów zanim ktokolwiek zdążyłby cofnąć deploy.

środowisko testowe zatrzymał release. wycofanie zmian na kopii testowej potwierdził, że sama wtyczka SEO jest niewinna, gdy motyw inicjalizuje sesję przed hookiem WordPressa. Motyw dostał poprawkę, checklista formularza (wysłanie, mail potwierdzenia, zapis do CRM, purge cache) przeszła, dopiero potem produkcja. Nie ma tu nazwy firmy, bo to kształt zdarzenia, nie case study z logotypem. Jest mechanizm: najpierw kopia, potem produkcja.

Ten sam kształt wraca przy wtyczce consent, która po aktualizacji wysyła Meta Pixel przed zgodą cookie, przy polu KVK znikającym z formularza po patchu ACF i przy „drobnej” aktualizacji, która wyłącza webhook CRM. Rotterdam nie wybacza tego ciszej niż inny rynek. Wygląda to gorzej, bo obok siedzi ktoś, kto pyta o AP, o AVG albo o slot w kalendarzu kampanii.

#WordPress Meetup 010 i praktyka, której nie widać w panelu hostingu

WordPress Meetup 010 spotyka się regularnie w ekosystemie holenderskim (meetup.com/rotterdam-wordpress-meetup). WordCamp Europe 2023 odbył się w Ahoy Rotterdam, więc lokalna społeczność zna standardy Core, uprawnień i integracji płatniczych lepiej niż na wielu rynkach europejskich. To nie jest kanał sprzedaży. To jest miejsce, w którym widać, jak lokalni maintainerzy aktualizują Core, jak rozmawiają o uprawnieniach i o Mollie sandbox. Opieka, która nigdy nie wychodzi poza ticket, gubi ten kontekst: w Rotterdamie część zespołów i tak siedzi po stronie logistyki i B2B i usłyszy te same pytania o AVG i hosting w EOG na meetupie w Kop van Zuid.

WP-CLI w utrzymaniu nie jest ozdobą meetupową. To sposób, żeby aktualizację, różnicę wtyczek i eksport listy użytkowników zrobić powtarzalnie, z logiem, bez klików w wp-admin na produkcji. Po sesji o bezpieczeństwie w społeczności argument „zrobimy to ręcznie w panelu” brzmi jeszcze gorzej.

#Miesięczny rytm, onboarding i przejęcie bałaganu

Onboarding to audyt, nie kick-off z prezentacją. Inwentaryzacja wtyczek, wersja PHP, cron, poczta, SSL, WAF, czy kopia w ogóle się odtwarza, gdzie stoi serwer, kto ma dostęp SFTP i do wp-admin, czy są konta-widma po agencji, która zniknęła. Baseline Lighthouse na stronie głównej i na najważniejszym formularzu B2B albo panelu partnera. Lista ryzyk z priorytetem: najpierw to, co psuje odtworzenie i bezpieczeństwo, potem to, co psuje konwersję albo publikację.

Pierwszy cykl aktualizacji na stagingu jest częścią onboardingu, nie „bonusem w miesiącu drugim”. Jeśli stagingu nie ma, jego postawienie jest pracą startową. Serwis B2B albo logistyczny w Rotterdamie bez kopii testowej nie wchodzi w stały abonament z otwartymi auto-update.

Miesiąc stały: okno aktualizacji poza Koningsdag i Black Friday, skan, przegląd logów WAF, test odtworzenia kopii w uzgodnionym cyklu, krótki raport. Raport ma metryki (uptime z monitoringu, błędy 5xx, czas odpowiedzi, lista wgranych wersji), decyzje (wtyczka X zostaje, wtyczka Y do wymiany) i residualne ryzyko (host poza EOG, brak 2FA u redakcji, brak umowy powierzenia, cache bez reguły dla sesji, freeze Koningsdag jeszcze nie wpisany). Bez residualnego ryzyka raport jest broszurą.

Przejęcie zaniedbanej instalacji zaczyna się od tej samej listy, tylko dłuższej. Stary PHP, wtyczka page buildera bez łatek, kopia tylko na tym samym dysku co produkcja, hasło admin we wpisie w Notion, formularz z trzema wtyczkami integracyjnymi naraz, Redis, który trzyma sesje w trakcie redirectu. Pierwszy miesiąc to remediacja. Stała opieka zaczyna się, gdy da się bezpiecznie wgrać łatki.

Budowa od zera albo przebudowa motywu to już inna usługa: programista WordPress w Rotterdamie. Sklep, checkout, iDEAL i BTW: programista WooCommerce w Rotterdamie. Opieka nie udaje, że jest projektem wdrożeniowym. Gdy w utrzymaniu wychodzi, że motyw trzeba napisać od nowa, to idzie jako osobne zlecenie, na piśmie.

#Wydajność przy skoku ruchu kampanii i użytkownikach z Holandii

Origin w EOG nie naprawi ciężkiego motywu z galeriami produktowymi. HTTP/3, Brotli, AVIF, lazy load, który nie psuje LCP hero, cache, który nie trzyma prywatnej sesji w trakcie redirectu, ograniczenie wtyczek z zapytań SQL na każdej podstronie: to nadal robota utrzymaniowa. Core Web Vitals mierzymy na realnych URL-ach z formularzami B2B, nie na pustej instalacji. INP psuje się od skryptów czatu, od Mollie.js ładowanego w złej kolejności i od tag managera, który marketing dodał poza ticketingiem. Opieka, która nie widzi GTM, będzie gonić „optymalizację obrazków” w nieskończoność.

Dla serwisu B2B w Rotterdamie liczy się czas do pierwszego bajtu z sieci w Holandii i w Beneluksu, nie tylko z telefonu w centrum miasta. Monitoring z jednego regionu USA kłamie. Punkt pomiaru w EOG jest częścią kontraktu operatorskiego, nie dodatkiem. Strona z pełnoekranowymi zdjęciami produktów umiera na LCP od nieoszczędnych JPEG-ów szybciej niż od „słabego hostingu”. Przed Koningsdag albo Black Friday idzie osobny przegląd cache, limitów PHP i CDN; po evencie idzie ścinka landingów, które mają zostać jako archiwum, i tych, które mają dostać 301.

#Bezpieczeństwo jako lista decyzji, nie jako plakietka

HTTPS z HSTS tam, gdzie infrastruktura to uniesie. Nagłówki ograniczające XSS. 2FA. Minimum kont administratorskich. Zakaz wtyczek „nulled”. Zakaz edytora plików w wp-admin na produkcji. Rotacja haseł po odejściu freelancerów. Test odtworzenia kopii, bo kopia, której nikt nie odtwarzał, jest plikiem. Przy danych osobowych: umowa powierzenia, lista podprocesorów (host, CDN, poczta, analityka, bramka płatności), procedura naruszenia pod AVG.

To nie jest certyfikat ISO sprzedawany z abonamentem. To jest lista, którą da się odhaczyć przy onboardingowym audycie i wrócić do niej co kwartał. Klient z firmy logistycznej w Kop van Zuid, z biura w Delfshaven albo z dostawcy IT z Rotterdam Science Tower i tak przyniesie własną checklistę. Lepiej mieć swoją wcześniej. Dokumentacja hardeningu WordPress, niezależna od miasta, jest w WordPress Developer Handbook. Opieka w Rotterdamie dodaje do niej kalendarz freeze Koningsdag i Black Friday, pytanie o AP oraz jawny opis rezydencji w EOG.

#Rodzeństwo w Holandii i w Beneluksu

Ten sam model opieki działa w innych holenderskich miastach i w sąsiednich stolicach Beneluksu, z tym samym runbookiem i innym kontekstem lokalnym:

• Opieka techniczna WordPress w Amsterdamie
• Opieka techniczna WordPress w Antwerpii
• Opieka techniczna WordPress w Brukseli

#Jak zaczynamy, bez zaliczek w procentach na stronie

Zakres, godziny reakcji i cena są indywidualne i lądują w umowie przed startem. Na tej stronie nie ma podziału płatności na transze procentowe i nie ma tabeli pakietów. Krótki opis serwisu, stacku, hostingu i tego, czy jest środowisko testowe, wystarczy, żeby zaproponować audyt onboardingu.

Kontakt: formularz. W zgłoszeniu przydaje się lokalizacja hostingu, lista wtyczek albo dostęp do stagingu, oraz informacja, czy serwis musi zostać w EOG i czy w najbliższych tygodniach jest Koningsdag, Black Friday albo szczyt kampanii sezonowej. Z tego powstaje plan: co naprawiamy zanim w ogóle wejdziemy w miesięczny rytm, a co zostaje w kadencji.

Opieka w Rotterdamie ma sens, gdy serwis już niesie biznes i trzeba go nie zepsuć. Gdy trzeba go dopiero zbudować, wracamy do developmentu. Gdy trzeba go utrzymać przy Koningsdag, formularzach B2B, parze NL/EN i AVG pod AP, zostajemy przy tym, co ta strona opisuje: środowisko testowe, kopia, WAF, dziennik, compliance po stronie klienta, hosting w EOG i runbook, który da się pokazać audytorowi bez rekonstruowania historii z pamięci.