Realny koszt utrzymania i opieki technicznej sklepu w Toruniu w 2025 roku to zwykle 300–600 zł/mies. za pakiet podstawowy (2 h), 700–1500 zł/mies. za standard (6 h) i 1800–4000 zł/mies. za zakres rozszerzony (15 h). Poza pakietem stawka godzinowa wynosi 130–220 zł/h netto dla PrestaShop i WooCommerce — to widełki rynkowe dla Polski, a nie cennik DropDigital. Sklep z około 300 zamówieniami miesięcznie zużywa średnio 5–7 godzin pracy technicznej, co daje realny koszt 750–1400 zł/mies. Poniżej znajduje się część organizacyjna: najczęstsze błędy przy podpisywaniu umowy, checklista pytań do dostawcy i odpowiedzi na pytania z zapytań ofertowych. Szerszy zakres usług opisujemy w sekcji utrzymanie stron internetowych.
Liczba jest w pierwszym zdaniu, bez rozgrzewki: utrzymanie i opieka techniczna sklepu w Toruniu w 2025 roku to 300–600 zł/mies. za pakiet podstawowy, 700–1500 zł/mies. za standard i 1800–4000 zł/mies. za zakres rozszerzony. To widełki rynkowe dla Polski, a nie cennik DropDigital — mają służyć jako punkt odniesienia, kiedy porównujesz oferty.
Cena wynika z liczby godzin, nie z „wielkości sklepu” rozumianej marketingowo:
| Pakiet | Godziny pracy w miesiącu | Widełki netto/mies. | Co zwykle obejmuje |
|---|---|---|---|
| Podstawowy | 2 h | 300–600 zł | aktualizacje, backup, monitoring uptime i SSL, reakcja na awarie |
| Standard | 6 h | 700–1500 zł | powyższe plus drobne zmiany w szablonie, poprawki koszyka i płatności |
| Rozszerzony | 15 h | 1800–4000 zł | powyższe plus rozwój funkcji, optymalizacja wydajności, wsparcie przy kampaniach |
Podział na „w pakiecie” i „płatne osobno” to miejsce, w którym najczęściej dochodzi do sporu. Klient słyszy „masz opiekę”, a potem dostaje fakturę za dodanie nowej metody płatności. Obie listy powinny być wpisane w umowę punkt po punkcie, nie w formie ogólnika „drobne prace techniczne”.
W cenie abonamentu:
Płatne osobno (prace projektowe, wyceniane przed startem):
Reguła 30 minut. Zadanie poniżej progu wchodzi w pakiet bez pytania. Powyżej progu dostajesz szacunek godzinowy („to 2–3 h, tj. X zł”) i praca startuje dopiero po akceptacji. Bez takiego mechanizmu abonament staje się workiem bez dna — dla obu stron.
Raport miesięczny. Żądaj dokumentu z listą zadań, datą wykonania, czasem w minutach oraz sumą wykorzystanych godzin z pakietu. Bez raportu nie sprawdzisz, czy 6 h zostało faktycznie przepracowane, czy tylko zafakturowane. Dobry raport pokazuje też, ile godzin przechodzi na kolejny okres i co zostało przesunięte.
Cena pakietu zależy od tego, na czym stoi sklep. Ten sam zakres przy standardowym WooCommerce i przy mocno zmodyfikowanym PrestaShop to dwie różne prace i dwie różne liczby godzin.
PrestaShop. Aktualizacja core przy nadpisaniach w katalogu override/ i własnych modułach wymaga testów na stagingu oraz ręcznego przenoszenia zmian. Typowo doliczasz +20–30% wobec standardowego WooCommerce, a przy kilku modułach pisanych na zamówienie różnica bywa większa. Jak wygląda struktura override i modułów, opisuje dokumentacja developerska PrestaShop — warto ją znać, bo to ona decyduje, jak droga będzie każda aktualizacja.
WooCommerce. Koszt rośnie z liczbą aktywnych wtyczek. Do 15–20 wtyczek aktualizacja jest przewidywalna. Powyżej 25 aktywnych wtyczek ryzyko konfliktów rośnie skokowo: dwie wtyczki modyfikujące koszyk albo pola checkout potrafią się nadpisać i wygenerować błąd tylko przy konkretnej kombinacji płatności i kodu rabatowego. Każda wtyczka to dodatkowo osobne źródło aktualizacji do przetestowania po zmianie PHP.
WordPress (strona firmowa + sklep). Abonament bazowy jest niższy, bo mniej ruchomych części. Uwaga na sklepy na starych szablonach z page builderami: motywy z lat 2018–2020 oparte na Elementorze czy WPBakery często blokują podniesienie PHP do 8.2/8.3 i wymagają przepisania szablonu. To już projekt, nie abonament.
| Platforma | Typowy czas reakcji na aktualizację | Ryzyko przestoju | Widełki pakietu standardowego (6 h) |
|---|---|---|---|
| PrestaShop 1.7/8.x, standard | 2–4 h | średnie | 800–1500 zł/mies. |
| PrestaShop, mocno zmodyfikowany core i moduły własne | 4–8 h | wysokie | 1100–1900 zł/mies. |
| WooCommerce do 20 wtyczek | 1–2 h | średnie | 700–1500 zł/mies. |
| WooCommerce 25+ wtyczek | 3–5 h | średnie, rośnie z liczbą wtyczek | 900–1800 zł/mies. |
| WordPress + sklep na nowym szablonie | 1–2 h | niskie | 600–1200 zł/mies. |
| WordPress + sklep na starym szablonie z page builderem | 2–4 h, często blokada aktualizacji PHP | wysokie | 900–1600 zł/mies. |
Trzy modele rozliczeń różnią się nie stawką za godzinę, a tym, kto ponosi ryzyko niewykorzystanego czasu.
Skąd bierze się cena ryczałtu? Wykonawca bierze średnie zużycie (np. 6 h) i dokłada bufor na szczyty (4 h). Razem 10 h × 160 zł = 1600 zł, ale w cenniku widzisz 2500 zł, bo ryzyko jest po jego stronie. W spokojnym miesiącu, gdy zużyjesz 6 h, płacisz za 4 h, których nie wykorzystałeś — 640 zł miesięcznie, 7680 zł rocznie.
Dlatego w każdej ofercie żądaj rozbicia: liczba godzin × stawka plus ewentualne dopłaty (SLA, monitoring, licencje). Kwota bez rozbicia nie jest wyceną, tylko deklaracją. Proś też o raport z listą zgłoszeń i czasem pracy — rozliczenie w blokach 15-minutowych jest uczciwsze niż zaokrąglanie do pełnych godzin. Pytanie kontrolne do wykonawcy: „ile godzin i na co przeznaczyliście w tej kwocie?”. Brak odpowiedzi oznacza, że sprzedawca sam nie wie, co sprzedaje, a nadwyżkę policzy ci po 300 zł/h. Model godzinowy jest uczciwszy, bo widzisz, za co płacisz. Szerszy zakres prac opisuję przy utrzymaniu stron internetowych.
| Model | Co kupujesz | Kiedy się opłaca | Gdzie jest ryzyko |
|---|---|---|---|
| Abonament godzinowy (rolling) | 6 h/mies., nadwyżka na kolejny miesiąc | Sklep z powtarzalną, drobną pracą | Nadwyżka poza pakietem bywa wyceniana wyżej |
| Pakiet 12 miesięcy | 72 h do wykorzystania w rok | Planowana migracja lub przebudowa szablonu | Niewykorzystane godziny przepadają |
| Nielimitowany ryczałt | Stała kwota z listą wyłączeń | Firmy z bardzo zmiennym wolumenem zgłoszeń | Płacisz za bufor, którego zwykle nie zużyjesz |
Bez zapisu o SLA każda awaria trafia do kolejki „kiedyś”. Dostawca nie ma obowiązku reagować w poniedziałek, a sklep traci zamówienia. Trzy poziomy, które warto wpisać do umowy, wyglądają tak:
Kluczowe rozróżnienie: reakcja to potwierdzenie zgłoszenia i diagnoza („wiemy, że nie przechodzą płatności, przyczyną jest błąd modułu płatności”). Rozwiązanie to wdrożenie poprawki i potwierdzenie, że działa. Mylenie tych pojęć to najczęstszy spór przy rozliczeniu umowy. Wpisuj oba czasy osobno.
Do tego klasyfikacja zgłoszeń: P1 — sklep nie działa lub płatności nie przechodzą; P2 — kluczowa funkcja nie działa (logowanie, koszyk, wysyłka); P3 — kosmetyka i zmiany treści. Bez tego dostawca traktuje baner na stronie głównej tak samo jak awarię bramki płatniczej.
Monitoring zewnętrzny co 1–5 min (np. po kodach HTTP: 200 to odpowiedź poprawna, 5xx to błąd serwera) powinien być w cenie pakietu standardowego, z alertami na e-mail i SMS bez dopłaty. Jak to wygląda u nas przy sklepach B2B, opisuje przykład zakresu dla firmy: utrzymanie i opieka techniczna sklepów Toruń dla firmy. Definicje kodów 4xx i 5xx znajdziesz w RFC 9110 — HTTP Semantics.
| Poziom SLA | Czas reakcji | Dla kogo | Wpływ na cenę |
|---|---|---|---|
| Standard | 24 h w dni robocze | Sklep z niewielkim udziałem sprzedaży online | W cenie pakietu podstawowego (300–600 zł/mies.) |
| Rozszerzony | 8 h w dni robocze | Sklep robiący większość obrotu online | +20–40% do abonamentu |
| Krytyczny | 2 h, także w weekend | Sklep sezonowy, kampanie, duży wolumen zamówień | Wycena indywidualna |
Większość ofert nie kłamie wprost — pomija. Oto siedem zapisów, które podnoszą realny koszt o 30–80% w skali roku.
Szybki test przed podpisaniem — pięć pytań i to, co powinieneś usłyszeć. Jak wygląda przygotowanie do takiej rozmowy, opisuję w materiale o tym, co ustalić przy utrzymaniu sklepu w Toruniu.
| Pytanie do sprzedawcy | Dobra odpowiedź | Sygnał ostrzegawczy |
|---|---|---|
| Ile godzin zawiera pakiet i co się dzieje po przekroczeniu? | Konkretna liczba i stawka nadwyżki zbliżona do pakietowej | „To zależy”, brak stawki w umowie |
| Kiedy ostatnio odtwarzaliście backup? | Data, środowisko, czas odtworzenia | „Backupy robi hosting” |
| Czy aktualizacje idą najpierw na staging? | Tak, klon + test + wdrożenie w oknie serwisowym | „Aktualizujemy na produkcji, to szybkie” |
| Czy zmiany treści i szablonu są w pakiecie? | Tak, z limitem czasu lub osobną stawką | „To nie jest praca techniczna” |
| Co dostaję na koniec współpracy? | Dostępy, dokumentacja, eksport zgłoszeń | Brak zapisu w umowie |
Podpisanie umowy nie naprawia sklepu w jeden dzień. Realny harmonogram startu to 3–4 tygodnie, a pierwszy pełny raport z efektów dostajesz po 30 dniach. Poniżej rozkład na pięć kroków — z czasem i tym, co powinieneś dostać na piśmie.
Krok 1: audyt techniczny (2–4 h). Sprawdzamy wersję PHP i MySQL i porównujemy ją z macierzą zgodności CMS-a (dla PrestaShop aktualne wymagania są w dokumentacji dla deweloperów), listę modułów z datami ostatnich aktualizacji, wolne zasoby VPS (RAM, CPU, dysk), czasy odpowiedzi TTFB, kody 5xx w logach serwera i PHP (klasa błędów serwera wg RFC 9110), rozmiar bazy, konfigurację cronów, certyfikat SSL i to, czy backup w ogóle się wykonuje. Po samych logach widać, czy problemem jest hosting, moduł czy baza.
Krok 2: raport i wycena. Dostajesz listę ryzyk w dwóch grupach: „teraz” (0–14 dni) i „w ciągu kwartału”. Każda pozycja z wyceną w godzinach. Typowe „teraz”: PHP po końcu wsparcia, nieaktualizowany moduł płatności, backup trzymany na tym samym serwerze co sklep.
Krok 3: staging i backupy. Środowisko staging na subdomenie (noindex + Basic Auth), kopia bazy, osobny plik konfiguracyjny. Backup: baza codziennie, pliki codziennie lub co tydzień, retencja 30 dni, kopia poza VPS. Test odtworzenia na innym serwerze — bez tego nie masz backupu, masz nadzieję.
Krok 4: monitoring, alerty, SLA. Uptime sprawdzany co minutę z dwóch lokalizacji, alert e-mail/SMS, kontrola wygasania SSL z 30-dniowym wyprzedzeniem, alert na dysk powyżej 85%. Kanał zgłoszeń: e-mail plus ticketing, żeby każde zgłoszenie miało numer i termin. Standardowy zakres takich prac opisujemy w sekcji utrzymanie stron internetowych.
Krok 5: pierwszy miesiąc. Plan aktualizacji etapowych: staging → test → produkcja, jedno ryzykowne wdrożenie naraz, okno serwisowe poza szczytem zamówień. Na koniec raport godzinowy (ile godzin i na co) i przegląd po 30 dniach. Audyt jest płatny osobno i nie zobowiązuje do podpisania umowy na opiekę — to celowe.
| Krok | Czas | Co dostajesz |
|---|---|---|
| 1. Audyt techniczny | 2–4 h | Wersje PHP/CMS, lista modułów, zasoby VPS, błędy z logów |
| 2. Raport i wycena | 2–3 dni | Ryzyka „teraz” i „w ciągu kwartału” + wycena w godzinach |
| 3. Staging i backupy | 3–5 dni | Kopia sklepu, retencja 30 dni, kopia poza VPS, test odtworzenia |
| 4. Monitoring i SLA | 1–2 dni | Alerty uptime/SSL/dysk, ticketing, SLA z czasem reakcji i naprawy |
| 5. Pierwszy miesiąc | 30 dni | Plan aktualizacji etapowych, raport godzinowy, przegląd po 30 dniach |
Ta lista działa z dowolnym wykonawcą: agencją, freelancerem, firmą hostingową. Zadaj te pytania przed podpisaniem, nie po.
Zanim podpiszesz, przeczytaj, co ustalić w umowie na opiekę techniczną sklepu w Toruniu, a potem porównaj stawki z cennikiem utrzymania sklepów w Bydgoszczy i cennikiem dla Szczecina. Widełki w tych miastach są zbliżone, więc jeśli oferta odbiega o 100% w którąkolwiek stronę, zapytaj dlaczego.
Kupowanie pakietu „nielimitowanego”, w którym nie ma katalogu prac wyłączonych. Cena takiego abonamentu musi pokryć średnie zużycie godzin plus bufor, więc w praktyce płacisz także za godziny, których nikt nie wykorzysta.
Jak wykryć: W umowie pojawia się słowo „nielimitowany”, ale nie ma listy prac wyłączonych ani przykładowego miesięcznego zużycia godzin. Zapytaj, ile godzin średnio zużywa sklep o podobnej skali.
Jak naprawić: Poproś o pisemny wykaz wyłączeń (nowe moduły, integracje, migracje, prace projektowe) oraz o dwa anonimizowane raporty miesięczne od innych klientów. Jeśli dostawca ich nie pokaże, to nie jest oferta nielimitowana, tylko nieokreślona.
Brak obowiązku raportowania godzin i zadań w abonamencie. Klient płaci stałą kwotę i nie ma jak sprawdzić, czy cokolwiek zostało zrobione.
Jak wykryć: W umowie nie ma ani jednego zdania o miesięcznym raporcie. Faktury przychodzą, a informacja zwrotna to „wszystko działa”.
Jak naprawić: Dopisz klauzulę: co miesiąc raport z listą zadań, liczbą przepracowanych godzin i saldem pakietu. Bez tego abonamentu nie da się zweryfikować, a różnica między 300 a 1500 zł/mies. staje się nieuzasadniona.
Aktualizacje core i wtyczek wykonywane bezpośrednio na produkcji, bez środowiska stagingowego.
Jak wykryć: Zadaj jedno pytanie: na jakim środowisku testujecie aktualizacje przed wdrożeniem? Odpowiedź „na produkcji, kopiujemy najpierw pliki” oznacza brak stagingu.
Jak naprawić: Wymagaj stagingu i kopii wykonanej bezpośrednio przed aktualizacją. Przy sklepie z 25+ aktywnymi wtyczkami lub mocno zmodyfikowanym core PrestaShop aktualizacja bez testu to najprostsza droga do przestoju w środku dnia handlowego.
Backupy, których nikt nigdy nie odtworzył. Kopia, która nie została przetestowana, nie jest kopią — jest plikiem o nieznanej zawartości.
Jak wykryć: Poproś o datę ostatniego testu odtworzenia kopii na środowisku testowym. Jeśli dostawca nie potrafi jej podać, testu nie było.
Jak naprawić: Ustal test odtworzenia co kwartał, z krótkim potwierdzeniem na piśmie: data, środowisko, czas odtworzenia. Zapisz też, jak długo trwa odtworzenie sklepu po awarii — to liczba, którą warto znać przed Black Friday.
Prace projektowe wrzucane do worka „drobnych poprawek”. Nowy moduł, integracja z ERP czy zmiana szablonu nagle okazują się elementem abonamentu — albo wręcz odwrotnie, abonament nie wystarcza i pojawia się faktura bez ostrzeżenia.
Jak wykryć: Sprawdź, czy umowa definiuje próg drobnej poprawki. Brak progu oznacza, że granica jest uznaniowa i zawsze na niekorzyść jednej ze stron.
Jak naprawić: Wpisz regułę 30 minut: zadania poniżej progu są w pakiecie, powyżej wyceniane godzinowo. Każda praca powyżej progu musi mieć szacunek czasu podany przed startem i zaakceptowany przez klienta.
Traktowanie oferty 99 zł/mies. jako pełnej opieki technicznej.
Jak wykryć: Sprawdź, co realnie zawiera najtańsza oferta. Jeśli w pakiecie jest tylko automatyczna aktualizacja i backup, nie ma tam monitoringu, reakcji na błędy 500 ani drobnych poprawek.
Jak naprawić: Porównuj oferty na poziomie zakresu, nie ceny. Dopytaj o czas reakcji na błąd 500, monitoring certyfikatu SSL i limit drobnych poprawek. Dopiero potem zestawiaj kwoty.
Utrzymanie i opieka techniczna sklepu w Toruniu kosztuje w 2025 roku od 300 zł/mies. za pakiet podstawowy do 4000 zł/mies. za zakres rozszerzony, a stawka poza pakietem to 130–220 zł/h netto. Kluczowe nie są widełki, lecz to, co jest w nich zapisane: liczba godzin, próg drobnej poprawki, staging, test backupu i miesięczny raport. Oferta za 99 zł/mies. nie zawiera pełnej opieki — zawiera aktualizację i backup, a wszystko inne jest płatne osobno. Przed podpisaniem umowy porównaj zakres, nie cenę.
Widełki rynkowe dla Polski to 300–600 zł/mies. za pakiet podstawowy (około 2 h), 700–1500 zł/mies. za standard (około 6 h) i 1800–4000 zł/mies. za zakres rozszerzony (około 15 h). Poza pakietem stawka wynosi zwykle 130–220 zł/h netto. Sklep z około 300 zamówieniami miesięcznie zużywa średnio 5–7 godzin pracy technicznej, co daje 750–1400 zł/mies.
Stawki godzinowe są w praktyce ogólnopolskie — nie ma odrębnego cennika dla Torunia, Bydgoszczy czy Szczecina. Różnice pojawiają się przy pracy na miejscu (dojazd, prace poza godzinami) albo gdy dostawca ma lokalnie dostępnego specjalistę od konkretnej platformy. Wartość dodaje nie miasto, lecz kompetencje w danym stacku.
W pakiecie najczęściej mieszczą się: aktualizacje core/CMS i wtyczek testowane na stagingu, backupy z testem odtworzenia, monitoring uptime i certyfikatu SSL, reagowanie na błędy 500/404 oraz drobne poprawki do 30 minut. Płatne osobno są prace projektowe: nowe moduły, integracje ERP, migracja platformy, zmiany w szablonie, wdrożenie nowej metody płatności i optymalizacja Core Web Vitals powyżej 2 h.
Przy ryczałcie nielimitowanym cena musi pokryć średnie zużycie godzin plus bufor na miesiące z awariami, więc klient płaci także za godziny, które nie zostaną wykorzystane. Model godzinowy (abonament rolling albo pakiet ważny 12 miesięcy) pokazuje realne zużycie i pozwala je zweryfikować w raporcie. Jeśli oferta nielimitowana nie ma katalogu wyłączeń, nie jest to pakiet bez limitu, tylko pakiet o nieokreślonym zakresie.
Zwykle tak. W PrestaShop aktualizacja jest droższa, gdy core jest mocno zmodyfikowany, a sklep korzysta z wielu modułów własnych albo porzuconych — typowo o 20–30% wobec standardowego WooCommerce. W WooCommerce koszt rośnie wraz z liczbą aktywnych wtyczek: powyżej 25 ryzyko konfliktów rośnie skokowo. Sama platforma nie przesądza ceny — decyduje liczba modyfikacji poza standardem.
Poproś o miesięczny raport z listą zadań i liczbą godzin oraz o saldo pakietu na koniec miesiąca. Sprawdź kilka pozycji w praktyce: czy zmiana jest widoczna na stronie, czy data wdrożenia się zgadza, czy opis zadania da się powiązać z Twoim zgłoszeniem. Brak raportu oznacza, że abonamentu nie da się zweryfikować — a to pierwszy zapis, o który warto walczyć w umowie.
W standardowych pakietach nie. Migracja platformy, integracja ERP czy wdrożenie nowej płatności to prace projektowe z odrębnym szacunkiem czasu i harmonogramem. Powinny być wyceniane osobno, z podaniem liczby godzin przed startem — wtedy wiadomo, kiedy kończy się opieka, a zaczyna projekt.
Jeśli chcesz porównać swoją obecną umowę z realnym zakresem opieki, wyślij nam jej opis — powiemy, co jest w niej niedopowiedziane. Możesz też zacząć od przeglądu naszych usług utrzymania stron internetowych.