Od czego zacząć opiekę techniczną sklepu w Łęcznej

Pełne przejęcie sklepu zaczyna się od audytu wejściowego, a nie od pierwszego zgłoszenia klienta. Bez audytu stawkę abonamentu ustala się na wyczucie — i po dwóch miesiącach okazuje się, że realna praca nie mieści się w cenie.

Audyt techniczny wejścia. Sprawdzasz wersję PHP i to, czy producent jeszcze ją wspiera (daty EOL publikuje php.net), wersję platformy i jej gałąź, listę modułów lub wtyczek wraz z datą ostatniej aktualizacji, konfigurację serwera (memory_limit, max_execution_time, wersja MySQL/MariaDB), zadania cron oraz ważność certyfikatu SSL. Osobno wyłapujesz nietypowe rzeczy: pliki core nadpisane przez poprzedniego wykonawcę, custom code w szablonie, moduły wgrane ręcznie przez FTP.

Inwentaryzacja dostępów. W praktyce brakuje połowy z nich. Potrzebujesz: panelu hostingowego, SSH/FTP, konta administratora w PrestaShop lub WP, dostępu do DNS u rejestratora domeny, panelu płatności, kont kurierskich (InPost, DPD, DHL), poczty na domenie i Google Search Console. Dane logowania trafiają do menedżera haseł, nie do dokumentu na dysku biurowym.

Zasada numer jeden: najpierw pełny backup plików i bazy, dopiero potem jakiekolwiek zmiany. Kopia leżąca na tym samym hostingu nie jest backupem — musi być poza serwerem i mieć przetestowane odtworzenie na subdomenie.

Orientacyjny czas audytu to 4–8 godzin dla sklepu do 5 000 SKU. Przy 20 000 SKU, z ERP i kilkoma integracjami: 12–16 godzin. Efekt to lista 10–20 zadań do zamknięcia w pierwszych 30 dniach. Jeśli prowadzisz mniejszy sklep, kolejność kroków znajdziesz w materiale o tym, od czego zacząć opiekę nad sklepem w Chełmie.

Co realnie obejmuje utrzymanie sklepu, a co nie

Podział na „w opiece” i „poza opieką” to najczęstsze źródło sporów z wykonawcą. Klient wychodzi z założenia, że skoro płaci co miesiąc, to nowy moduł B2B „też się należy”. Wykonawca traktuje to jako osobny projekt. Obie strony mają po części rację — problem w tym, że umowa tego nie rozstrzyga.

W opiece: aktualizacje bezpieczeństwa platformy i modułów, monitoring dostępności (sprawdzenie co 1–5 minut z alertem mailem lub SMS-em), backupy bazy i plików z retencją, przywrócenie sklepu po awarii, obsługa zgłoszeń według SLA, nadzór nad certyfikatem SSL, drobne poprawki CSS/PHP do umownego limitu godzin, przegląd logów błędów.

Poza opieką, czyli płatne ekstra: nowe funkcje (moduł B2B, integracja z ERP albo Subiektem, kolejna bramka płatności), redesign, migracja na inną platformę, masowe zmiany cenników, prace przy treściach i kampaniach. To zadania projektowe — wyceniane osobno, z własnym terminem.

Wskaźnik z praktyki: w typowym MŚP 70–80% miesiąca zajmują drobne poprawki, a 20–30% incydenty. Jeśli u Ciebie jest odwrotnie i co tydzień gasisz pożar, problem leży w kodzie albo w hostingu, nie w samej opiece.

Wskazówka do umowy: wpisz limit godzin na drobne prace i stawkę za nadwyżkę — np. 4 h w pakiecie i 160–220 zł netto za każdą kolejną godzinę. Ustal też, kto decyduje, że zadanie jest „drobne”. Najprostsza definicja: zmiana nie rozszerza zakresu funkcjonalnego i zajmuje do 1 godziny.

SLA w praktyce: priorytety P1, P2, P3 i czasy reakcji

Zapis „reagujemy szybko” jest nieegzekwowalny. Sensowny SLA ma trzy poziomy i dwie odrębne miary — bez tego nie ma czego dochodzić.

P1 — sklep nie działa albo padły płatności. Reakcja do 1 h w godzinach pracy, naprawa do 4 h. P2 — błąd blokujący część zamówień, np. jedna metoda dostawy nie przelicza kosztów albo nie generują się etykiety. Reakcja do 4 h, naprawa do 1 dnia roboczego. P3 — kosmetyka i drobne poprawki: reakcja do 1 dnia roboczego, realizacja w kolejce zadań.

Czas reakcji to nie to samo co czas naprawy. Reakcja oznacza potwierdzenie przyjęcia zgłoszenia przez człowieka — z informacją, kto nad nim pracuje i na jakim etapie jest diagnoza. Automatyczna odpowiedź z formularza nie liczy się jako reakcja; zapisz to wprost, bo to najczęstszy trik wykonawców. Czas naprawy oznacza, że sklep znów przyjmuje zamówienia.

Godziny pracy i kanał zgłoszeń. Ustal konkretny przedział, np. 8:00–16:00, i wpisz, co dzieje się poza nim — czy P1 ma dyżur, czy czeka do rana. Najlepiej wypadają dwa kanały: mail na adres zespołu i telefon do konkretnego dewelopera, nie do ogólnego formularza. Formularz w trakcie awarii potrafi wrócić w kolejce dopiero po kilku godzinach.

Monitoring powinien rozpoznawać kody odpowiedzi HTTP: 5xx to błąd serwera, 503 to chwilowa niedostępność usługi — semantykę tych kodów opisuje RFC 9110 (HTTP Semantics). Jeśli monitoring sam wyłapie P1 i wyśle alert, nie tracisz czasu na telefon od klienta. Zapis o karach umownych (np. 5% abonamentu za przekroczenie progu) działa zaskakująco dobrze — uczciwy wykonawca go podpisuje.

Ile kosztuje utrzymanie sklepu — widełki w godzinach

Nie ma jednego cennika utrzymania sklepu. Jest stawka godzinowa i liczba godzin, które sklep realnie zjada w miesiącu. Dla prac utrzymaniowych i rozwojowych w regionie lubelskim spotkasz stawki 120–200 zł/h netto. Dolna granica to zwykle jednoosobowy wykonawca na telefon, górna — zespół z osobą prowadzącą klienta i miesięcznym raportem. Prace rozwojowe (nowa funkcja, integracja, moduł na zamówienie) wycenia się o 20–40% wyżej niż czyste utrzymanie.

Rozliczenie opiera się na pakiecie godzinowym. Trzy warianty, które najczęściej podpisuje się w Łęcznej i okolicach:

PrestaShop czy WooCommerce — co się psuje częściej w utrzymaniu

Obie platformy mają swoje typowe awarie i inaczej planuje się dla nich godziny. PrestaShop ma spójną architekturę — jeden system szablonów, jeden mechanizm override, jasny podział na moduły i hooki. Ceną jest to, że aktualizacje modułów są kosztowniejsze w obsłudze. Największe ryzyko to moduły od jednego autora, bez wydania od dwóch lat: wejście z 1.6/1.7 na 8.x potrafi je wyłączyć, a override'y nadpisać pliki szablonu. Każdy taki moduł trzeba sprawdzić na kopii, nie na produkcji.

WooCommerce aktualizuje się inaczej: wtyczki dostają wydania co kilka tygodni i realnie raz na kwartał któraś łamie koszyk, płatności albo dodawanie do koszyka. Drugi scenariusz to konflikt po aktualizacji WooCommerce i PHP — stara wtyczka rzuca fatal error i wywala całą stronę na biało. Trzeci: przełączenie na HPOS (High-Performance Order Storage) i wtyczki, które nadal czytają zamówienia z postmeta.

Wspólne minimum dla obu platform to PHP 8.1 lub nowsze. Sklep, który nie był aktualizowany przez 12 miesięcy, ma zwykle 3–5 ukrytych błędów do naprawy — brakujące tłumaczenia po aktualizacji, niedziałający e-mail potwierdzający, rozjechane stany magazynowe. Nie da się ich znaleźć bez testu regresyjnego po każdej aktualizacji:

• koszyk — dodanie, zmiana ilości, usunięcie, kod rabatowy
• płatność — pełna ścieżka do potwierdzenia u operatora
• wysyłki — przeliczenie kosztu i wybór metody
• e-mail potwierdzający i faktura — treść, załącznik, nadawca

Jeśli utrzymujesz sklep poza Łęczną, podobne różnice widać przy utrzymaniu i opiece technicznej sklepów w Chełmie, gdzie częściej trafiają się sklepy na WooCommerce z kilkunastoma wtyczkami.

Monitoring, kopie zapasowe i bezpieczeństwo — minimum techniczne

Monitoring zewnętrzny sprawdza sklep co 1–5 minut: dostępność i czas odpowiedzi serwera. Alert musi iść SMS-em lub mailem do osoby dyżurnej, nie do skrzynki biurowej, którą ktoś czyta raz dziennie. Warto odróżnić awarię serwera (kody 5xx) od zwykłego ruchu klientów (4xx) — semantykę tych kodów definiuje RFC 9110, więc przy konfiguracji alertów można wyciąć fałszywe powiadomienia o błędach 404. Sam uptime to za mało: raz na 15–30 minut powinna lecieć transakcja syntetyczna — dodanie produktu do koszyka i dojście do ekranu płatności. To wyłapuje sytuacje, w których strona odpowiada 200, ale koszyk jest zepsuty.

Backupy to drugi filar. Baza codziennie, pliki co tydzień, retencja minimum 30 dni, kopia trzymana poza serwerem produkcyjnym. Test odtworzenia raz na kwartał — na staging albo w kontenerze, nie „na produkcji po godzinach”. Backup, który nie został odtworzony, nie istnieje. Warto też pilnować, czy zadanie backupu nie pada po cichu: brak alertu o błędzie oznacza, że o braku kopii dowiesz się w dniu awarii.

Przejęcie sklepu od poprzedniego wykonawcy — jak to zrobić bezpiecznie

Sklep po poprzedniej firmie zwykle działa — problem pojawia się w dniu, w którym trzeba coś zmienić. Wtedy okazuje się, że hosting jest zarejestrowany na wykonawcę, repozytorium kodu nie istnieje, a hasła do bazy wysłano kiedyś mailem. Dlatego przejęcie zaczyna się od inwentaryzacji, nie od wdrożenia.

Zanim podpiszesz umowę z nowym wykonawcą, umów się ze starym na 60–90 minut i przejdź punkty z tabeli poniżej. Każdy z nich to konkretny plik, login albo dokument — nie „ogólne przekazanie projektu”. Trzy rzeczy muszą się zgadzać niezależnie od reszty.

• Kod w repozytorium GIT. Pełny dostęp do repo (GitHub, GitLab, Bitbucket) razem z historią commitów, nie tylko kopia plików na FTP. Historia pokazuje, co i kiedy zostało zmienione — bez niej każda poprawka to zgadywanie.
• Hasła przez menedżer haseł. Plik .env, wp-config.php w WordPressie, dane do bazy i panelu trafiają jako osobne wpisy do Bitwardena, 1Password albo KeePass, z dostępem dla Ciebie i drugiej osoby w firmie. Nie na mailu, nie w arkuszu Google, nie SMS-em.
• Serwer na Twoje konto. VPS lub hosting zamówiony na dane Twojej firmy, z fakturą na Twój NIP. Jeśli umowa hostingowa stoi na wykonawcę, to on decyduje, kiedy oddasz sobie pliki.

Osobno zaplanuj środowisko testowe: kopia sklepu na subdomenie (np. staging.twojadomena.pl) z zablokowanym indeksowaniem i wyłączonymi płatnościami. Bez tego każda aktualizacja modułu idzie prosto na klientów.

Procedura awaryjna, gdy poprzedni wykonawca przestaje odpowiadać: wysyłasz pismo z terminem 7 dni na wydanie dostępów, równolegle zgłaszasz się do supportu dostawcy hostingu i domeny z dowodem własności (faktura, umowa, dane firmy), zmieniasz wszystkie hasła i odtwarzasz sklep z ostatniej kopii. Rejestr w Biuletynie Informacji Publicznej ani wpis w CEIDG nie są tu do niczego potrzebne — wystarczy umowa cesji praw do kodu i faktyczny dostęp. Ten etap warto przejść z zespołem, który robi to regularnie — tak jak przy utrzymaniu i opiece technicznej sklepów w Lublinie lub przy przejmowaniu sklepów po poprzednim wykonawcy w Chełmie.

Najczęstsze pułapki przy wyborze opieki technicznej

W Łęcznej i okolicy te same błędy wracają w co drugiej rozmowie z właścicielem sklepu. Pięć poniżej kosztuje najwięcej.

• Gotowe moduły zamiast własnych rozwiązań. Kupujesz wtyczkę za 40–80 EUR rocznie, potem drugą, która ją łata, i trzecią do eksportu. Po dwóch latach płacisz więcej niż za jednorazowe rozwiązanie, a przy awarii słyszysz „to wina modułu, nie nasza”. Własny kod ma jednego odpowiedzialnego — wykonawcę, z którym masz umowę.
• Umowa bez zapisanych czasów. „Reagujemy szybko” to nie SLA. Potrzebujesz dwóch liczb osobno: czasu reakcji i czasu naprawy, oraz definicji P1 (sklep nie przyjmuje zamówień) i P2 (błąd utrudnia zakupy). Bez tego spór o „szybko” jest nierozstrzygalny.
• Deweloper-pośrednik. Rozmawiasz z handlowcem, zgłoszenie trafia do podwykonawcy, którego nie znasz. Pytaj wprost, kto dotknie kodu Twojego sklepu i czy ta osoba będzie wskazana w umowie.
• Brak środowiska testowego. Każda zmiana ląduje od razu na produkcji. Aktualizacja PHP albo modułu płatności potrafi wyłączyć koszyk na kilka godzin w środku dnia.
• Brak przekazania dokumentacji na koniec. Gdy kończysz współpracę, nie dostajesz repo, opisów ani dostępów — i zostajesz zamrożony u jednego wykonawcy, bo nikt nowy nie chce wchodzić w nieudokumentowany kod.

Praktyka przed podpisaniem: poproś o dwa przykłady incydentów z ostatnich 30 dni u innych klientów — co się stało, w jakim czasie naprawiono, kto to robił. Zapytaj też o zapis o przekazaniu dokumentacji i repozytorium w ciągu 14 dni od zakończenia umowy. Jeżeli dostawca tego unika, to sygnał. Warto porównać warunki z tego, co pokazujemy przy opie technicznej z konkretnym SLA dla sklepów w Hrubieszowie i przy pakietach utrzymania sklepów w Narolu.

Jak mierzyć efekt opieki: KPI dostępne dla właściciela

Opieka techniczna to usługa, którą da się rozliczyć liczbami. Właściciel nie musi rozumieć logów — wystarczy mu pięć wskaźników i miesięczny raport.

• Uptime 99,9% miesięcznie. Przy 30 dniach to maksymalnie około 43 minut niedostępności sklepu. Więcej niż to w miesiącu oznacza, że masz prawo do wyjaśnienia i do korekty stawki.
• Czas reakcji na P1 średnio poniżej 30 minut. Nie „deklarowany”, a mierzony z historii zgłoszeń: godzina przyjęcia zgłoszenia i godzina pierwszego kontaktu technika. Poproś o zrzut tej historii raz na kwartał.
• Liczba incydentów P1 i P2 miesięcznie. Pierwsze trzy miesiące powinny pokazywać trend w dół — najpierw spada liczba powtórek tych samych awarii, potem liczba zdarzeń w ogóle.
• Czas odtworzenia sklepu z backupu: do 60 minut. Sprawdzasz to jednym testem w kwartale — prosisz o odtworzenie kopii na staging i mierzysz czas zegarkiem.
• Porzucone koszyki. Po optymalizacji szybkości (LCP poniżej 2,5 s, INP poniżej 200 ms — definicje znajdziesz w materiałach o Web Vitals) wskaźnik porzuconych koszyków powinien spaść o kilka punktów procentowych w ciągu 4–8 tygodni.

Ustal w umowie, że raport KPI dostajesz do 5. dnia każdego miesiąca, z danymi źródłowymi, a nie samą oceną „wszystko działa”. Sposób liczenia tych wskaźników opisujemy szerzej przy utrzymaniu sklepów w Bełżcu i opiece technicznej sklepów w Biłgoraju.

Najczęstsze błędy i jak je wykryć

Lista kontrolna do odklikania

• Zakres opieki wypisany punkt po punkcie — Sprawdź, czy umowa wymienia aktualizacje bezpieczeństwa, monitoring, backupy i limit godzin na drobne poprawki — a nie tylko ogólne "utrzymanie".
• Limit godzin i stawka za nadwyżkę — Zweryfikuj kwotę za godzinę powyżej pakietu jeszcze przed podpisem. To najczęstsze źródło sporu w trzecim miesiącu współpracy.
• Przelewanie niewykorzystanych godzin — Ustal karencję 1–3 miesięcy. Bez tego zapisu płacisz za godziny, których nikt nie wykorzystał w spokojnym miesiącu.
• Czasy reakcji i naprawy dla P1, P2, P3 — Sprawdź, czy oba parametry są zapisane osobno i czy priorytety mają przykłady, np. "P1 — brak możliwości złożenia zamówienia".
• Godziny pracy wsparcia — Ustal, czy opieka działa 8:00–16:00, czy dłużej, i co dzieje się ze zgłoszeniem P1 wysłanym po godzinach. Zakres godzin wpływa na cenę pakietu.
• Kanał zgłoszeń i osoba kontaktowa — Mail zespołu plus numer telefonu do konkretnego dewelopera. Sprawdź, czy dane są aktualne, zanim ruszy współpraca.
• Backup: częstotliwość, retencja, lokalizacja — Minimum raz dziennie, kopia poza serwerem produkcyjnym, retencja 30 dni. Poproś o dowód — zrzut z panelu backupu.
• Test odtworzenia sklepu — Zaplanuj go raz na kwartał na kopii testowej. Backup, którego nigdy nie odtworzono, nie jest backupem.
• Monitoring dostępności i alerty — Sprawdź, czy monitorowany jest adres sklepu oraz płatności, z jaką częstotliwością (np. co minutę) i kto dostaje alert w środku nocy.
• SSL — kto pilnuje wygaśnięcia — Odnowienie certyfikatu powinno być w opiece. Sprawdź zapis o automatycznym odnowieniu i o tym, kto reaguje, gdy odnowienie się nie powiedzie.
• Wersje PHP i platformy — zasady aktualizacji — Ustal, kto decyduje o aktualizacji i w jakim oknie czasowym (np. środa, 6:00). Bezpieczne minimum to PHP 8.1 i wspierana wersja PrestaShop lub WooCommerce.
• Logi serwera i kody odpowiedzi 5xx — Sprawdź, czy wykonawca ma dostęp do logów i czy przegląda błędy 5xx zgodnie z RFC 9110. To najszybsza droga do wykrycia padającej integracji, zanim zauważą ją klienci.
• Lista wyłączeń z opieki — Nowe funkcje, integracje, redesign i migracja muszą być wypisane jako prace wyceniane osobno. Sprawdź to przed pierwszym zleceniem rozwojowym.
• Raport miesięczny i okres wypowiedzenia — Poproś o prosty raport: co zrobiono, ile godzin zużyto, co zostało otwarte. Ustal okres wypowiedzenia i termin przekazania dostępów oraz dokumentacji.

Najczęściej zadawane pytania

Źródła i materiały

• Google Search Central – Core Web Vitals
• Google Search Central – tworzenie treści dla ludzi
• Google Search Central – dane strukturalne
• RFC 9110 – HTTP Semantics
• web.dev – Core Web Vitals