Utrzymanie i opieka techniczna sklepu to nie to samo co hosting. Hosting to wynajęte miejsce na serwerze, a opieka to konkretna odpowiedzialność: kto aktualizuje PrestaShop lub WooCommerce, kto pilnuje płatności i InPostu, kto odtwarza sklep po awarii i w jakim czasie. Jeśli nie potrafisz odpowiedzieć na te pytania, nie masz opieki – masz tylko serwer i nadzieję. Poniżej znajdziesz zakres prac, typowy rytm miesiąca i realne widełki cenowe dla sklepów z Józefowa i okolic.
W ofertach powtarza się jedno słowo — „opieka” — a pod nim kryją się cztery różne warstwy. Warto je rozdzielić, bo każdą obsługuje inny podmiot i inne są skutki, gdy coś padnie.
Wsparcie po wdrożeniu to nie opieka. Gwarancja na wykonane prace (typowo 30–90 dni) obejmuje błędy w kodzie, który wykonawca sam napisał. Nie obejmuje nowej wersji API InPostu, wymuszonej aktualizacji PHP przez hostingodawcę, ataku ani zmian w cenniku przewoźnika. Opieka abonamentowa to stały zakres i zobowiązanie: kto reaguje, w jakim czasie i co raportuje.
Hosting to warstwa infrastruktury. Dostawca odpowiada za dostępność maszyny i sieci, nie za to, że moduł płatności przestał zwracać potwierdzenia. W typowym modelu: klient — treści, decyzje, dostępy; wykonawca — aktualizacje, monitoring, kopie, reakcja na incydenty; dostawca modułu — zgodność z nowymi wersjami. Jeśli w umowie nie ma tego podziału, sprawdź, jak wygląda utrzymanie i opieka techniczna sklepów w Zamościu — rozpisaliśmy to punkt po punkcie.
| Warstwa | Co obejmuje | Kto zwykle odpowiada |
|---|---|---|
| Aplikacja | PrestaShop / WooCommerce, moduły, motyw, wersja PHP | wykonawca w abonamencie |
| Serwer / VPS | CPU, RAM, dysk, SSL, poczta, PHP-FPM | dostawca hostingu |
| Integracje | InPost, DPD, DHL, płatności, ERP | wykonawca + dostawca usługi |
| Bezpieczeństwo i kopie | WAF, limity logowania, backupy, test odtworzenia | wykonawca w abonamencie |
Poniższa lista nadaje się do porównania z ofertami, które już dostałeś. Jeśli któraś pozycja nie występuje w cenniku, dopytaj — albo jest pominięta, albo płatna osobno.
W umowie zapisz, czy aktualizacje są w abonamencie, czy płatne osobno. Zapis „aktualizacje w cenie” często oznacza wyłącznie poprawki bezpieczeństwa.
Dobrze prowadzona opieka ma stały rytm, dzięki któremu wiadomo, kiedy dopytywać o postępy.
Odrębne są czas reakcji (potwierdzenie i start pracy) i czas naprawy (przywrócenie działania). Typowo: reakcja 1 h dla awarii krytycznej w godzinach 8–18, naprawa do 8 h roboczych, przywrócenie z kopii do 4 h.
| Poziom awarii | Przykłady | Czas reakcji | Czas naprawy |
|---|---|---|---|
| Krytyczna | sklep nie odpowiada, checkout zwraca 500, baza niedostępna, płatności nie księgują | do 1 h | do 8 h roboczych |
| Poważna | nie tworzą się etykiety InPost, nie działa jedna metoda dostawy, brak maili z potwierdzeniem | do 4 h | 1 dzień roboczy |
| Zwykła | literówka, błędny opis, zamiana banera, korekta w menu | 2 dni robocze | 2–5 dni roboczych z puli godzin |
Nie ma jednej ceny, bo nie ma jednego sklepu. Realne widełki abonamentu dla sklepów z Józefowa i okolic: pakiet podstawowy 250–600 zł/mc netto, standard 800–2000 zł/mc netto, rozbudowany od 2500 zł/mc netto w górę. Różnica między pakietami to nie „lepsza obsługa”, a liczba godzin i zakres odpowiedzialności: kto aktualizuje moduły, kto pilnuje webhooków płatności, kto reaguje, gdy sklep padnie w piątek o 20:00.
Prace poza abonamentem: 120–250 zł/h netto. 120–150 zł/h to zadania standardowe — konfiguracja, poprawki w szablonie, treści. 180–250 zł/h to integracje API, migracje, pisanie własnych modułów, praca z wydajnością bazy i serwera.
Dwa przykłady wyceny. Sklep z 500 SKU i 200 zamówieniami/mc: gotowy motyw, płatności online, jeden kurier. Abonament standard w dolnej granicy — około 800–1000 zł/mc, bo integracji jest mało i nie ma szczytów. Sklep z 5000 SKU i integracją ERP: dwukierunkowa synchronizacja stanów, cen i zamówień, własny moduł wysyłkowy, modyfikowany motyw. Start od 2000–3000 zł/mc, bo każdą aktualizację trzeba przetestować na kopii, zanim wejdzie na produkcję.
Pulę godzin ustalamy z wyprzedzeniem — np. 5 h/mc — i rozliczamy z miesięcznego raportu: lista zadań, czas, efekt. Nie „ryczałt na oko”, po którym nikt nie wie, co się właściwie stało. Jeśli wykonawca nie podaje stawki godzinowej i liczby godzin, nie masz podstawy do porównania ofert.
Ten sam sposób liczenia stosujemy w innych miastach regionu — utrzymanie i opieka techniczna sklepów w Zamościu opisuje identyczny zakres.
Cenę podnoszą: liczba integracji (każda to osobny punkt awarii), własne moduły (aktualizacja rdzenia może je zepsuć), niestandardowy motyw oraz stary stack — PrestaShop 1.6 i PHP 7.x nie dostają już poprawek bezpieczeństwa, więc opieka nad nimi to łatanie i planowanie migracji (dokumentacja deweloperska PrestaShop podaje wspierane wersje).
| Pakiet | Widełki netto / mc | Co zawiera | Dla kogo |
|---|---|---|---|
| Podstawowy | 250–600 zł | Aktualizacje, monitoring, kopie, 1–2 h prac | Mały sklep, kilka zamówień dziennie |
| Standard | 800–2000 zł | Powyższe + reakcja na zgłoszenia, integracje, wydajność, 3–6 h prac | Sklep z regularną sprzedażą i kilkoma integracjami |
| Rozbudowany | od 2500 zł | Powyższe + ERP, własne moduły, prace rozwojowe, stała osoba | Sklep jako główne źródło przychodu |
Policz oba warianty na kartce, zanim zdecydujesz.
Etat. Wynagrodzenie brutto programisty plus narzuty pracodawcy (składki, sprzęt, szkolenia) i czas na rekrutację. Dostajesz jedną osobę, która zna sklep, ale ma też urlop.
Freelancer na część etatu. 100–200 zł/h, przy 5 h/mc daje 500–1000 zł, czyli podobnie jak abonament standard. Problem nie leży w cenie, a w zastępowalności: jedno konto, jedna głowa, wiedza nieudokumentowana.
Abonament opieki to podobna pula godzin, ale z umową, czasem reakcji i drugą osobą, która ma dostępy.
Ryzyka przy samodzielnym utrzymaniu: urlop i choroba wypadają zawsze w najgorszym momencie; przy zmianie wykonawcy nikt nie wie, jak postawić sklep od zera; brak testowanych kopii; hasła w notatniku; aktualizacje robione „przy okazji” i nigdy nietestowane. Typowy scenariusz: aktualizacja modułu płatności w czwartek, w piątek wieczorem klient dzwoni, że nie można zapłacić, a nikt nie wie, gdzie jest kopia z przedwczoraj.
Progi, przy których opieka przestaje być opcją:
Kiedy samodzielne utrzymanie ma sens: gotowy szablon bez modyfikacji, brak integracji poza standardowym zestawem, ruch do 1000 sesji dziennie, właściciel ma czas i podstawy techniczne, a kilkugodzinny przestój jest do przyjęcia. Wtedy wystarczą dobre kopie, aktualizacje raz w miesiącu i monitoring. Te same progi stosujemy lokalnie — zobacz utrzymanie i opieka techniczna sklepów w Zwierzyńcu.
| Wariant | Koszt miesięczny | Kto reaguje przy awarii | Główne ryzyko |
|---|---|---|---|
| Etat (pełny) | Wynagrodzenie + narzuty, zwykle wielokrotność abonamentu standard | Ta jedna osoba | Urlop, choroba, rotacja |
| Freelancer (część etatu) | 500–1000 zł przy 5 h/mc, stawka 100–200 zł/h | Ta jedna osoba | Brak SLA i brak zastępcy |
| Abonament opieki | 800–2000 zł (pakiet standard) | Zespół według umowy | Jakość wykonawcy — sprawdź checklistą |
Ta checklista działa niezależnie od tego, kogo wybierzesz — także nas. Zadaj pytania na piśmie i porównaj odpowiedzi, bo ustne „będziemy reagować szybko” nie ma żadnej wartości przy awarii.
Kopie zapasowe to najczęściej pomijany punkt. Pytaj: gdzie leżą (muszą być poza serwerem produkcyjnym, u innego dostawcy), jak często są robione (baza codziennie, pliki co tydzień to minimum), jak długo trzymane i kto ma do nich dostęp. Kluczowe pytanie brzmi: kiedy ostatnio testowano odtworzenie i ile ono zajęło. Umów test raz na kwartał — na kopii, nigdy na produkcji. W umowie zapisz RTO (czas odtworzenia po awarii) i RPO (dopuszczalna utrata danych).
Zakończenie współpracy: przed podpisaniem ustal, że repozytorium Git, dostępy do serwera, DNS, panelu płatności i dokumentacja przechodzą na Ciebie, a nie „zostaną wydane na wniosek”. Sprawdź, czy umowa przewiduje okres przejściowy i wygaszenie dostępów wykonawcy.
Prace poza abonamentem: stawka zapisana w umowie, próg wliczony w pakiet (np. do 30 minut), a każda większa praca zatwierdzana mailem przed startem — z wyceną i terminem. Jeśli wykonawca nie pyta o zgodę przed dodaniem pozycji na fakturę, szukaj dalej.
| Co sprawdzić | Pytanie | Dobra odpowiedź | Czerwona flaga |
|---|---|---|---|
| SLA | Ile wynosi czas reakcji przy awarii krytycznej? | Konkretny czas w godzinach pracy i poza nimi, zapisany w umowie | „Zgłaszamy na bieżąco” |
| Kopie zapasowe | Gdzie leżą i kiedy testowano odtworzenie? | Poza serwerem produkcyjnym, test co kwartał, raport | „Mamy kopie na serwerze” |
| Własność kodu | Kto ma repozytorium po zakończeniu umowy? | Klient ma dostęp do Git od pierwszego dnia | „Kod przekażemy na wniosek” |
| Prace dodatkowe | Jak zatwierdzasz prace poza abonamentem? | Stawka z umowy + wycena mailem przed startem | Faktura z pozycjami, o których nie wiedziałeś |
Zapis „nielimitowane zmiany” nie oznacza nielimitowanej pracy. W praktyce kryje się za nim najczęściej 2–4 godziny miesięcznie. Jak to sprawdzić przed podpisaniem umowy: poproś o wykaz zgłoszeń z ostatnich trzech miesięcy — liczbę pozycji i łączny czas realizacji. Jeśli dostajesz tabelę z 40 zgłoszeniami i sumą 11 godzin, to jest realny poziom pakietu, a nie obietnica. Drugi test: zapytaj, co się dzieje, gdy w jednym miesiącu potrzeba 20 godzin i czy stawka za nadwyżkę jest zapisana w umowie, czy „do ustalenia”.
Brak SLA i brak systemu zgłoszeń to dwa objawy tego samego problemu: nie masz dowodu. Gdy zgłoszenia idą przez WhatsApp albo telefon, po miesiącu nikt nie odtworzy, ile trwała reakcja. Wymagaj numeru zgłoszenia, daty pierwszej odpowiedzi i daty zamknięcia. Bez tego przy sporze o kilkugodzinny przestój nie masz czym się podeprzeć.
Kopie zapasowe trzymane wyłącznie na tym samym serwerze co sklep to awaria zsumowana. Test jest prosty: niech wykonawca odtworzy jeden plik z kopii sprzed tygodnia na środowisko testowe i pokaże wynik. Jeśli backup leży na tym samym koncie hostingowym, awaria serwera zabiera jedno i drugie.
Vendor lock-in widać w trzech miejscach: brak dostępu do repozytorium kodu, moduły z licencją przypisaną do konta wykonawcy i brak dokumentacji własnych modyfikacji. Sprawdź, czy masz dostęp do repozytorium z historią zmian i czy moduły są zarejestrowane na Twoje konto. Zależności między modułami a kolejnymi wersjami PrestaShop opisuje dokumentacja deweloperska PrestaShop — warto zajrzeć do niej przed rozmową.
Najprostsze sygnały ostrzegawcze: brak miesięcznego raportu, brak pojęcia „okno serwisowe” w rozmowie i brak imienia oraz telefonu do konkretnej osoby odpowiedzialnej za Twój sklep.
| Pułapka w umowie | Jak to sprawdzić w 10 minut |
|---|---|
| „Nielimitowane zmiany” | Poproś o wykaz zgłoszeń i godzin z 3 miesięcy, policz średnią miesięczną |
| Brak SLA | Sprawdź, czy umowa podaje czas reakcji osobno dla P1, P2 i P3 |
| Brak ticketingu | Wyślij testowe pytanie mailem i sprawdź, czy dostaniesz numer zgłoszenia |
| Backup tylko na serwerze sklepu | Zażyczaj test odtworzenia jednego pliku na środowisko testowe |
| Brak dostępu do repozytorium | Poproś o konto w Git z prawem odczytu pełnej historii zmian |
| Moduły na licencji wykonawcy | Sprawdź, na czyim koncie są zarejestrowane i czy da się je przenieść |
| Brak raportów i okna serwisowego | Zapytaj o wzór raportu miesięcznego i konkretne godziny prac wdrożeniowych |
Obsługujemy sklepy z Józefowa, Zamościa, Zwierzyńca, Szczebrzeszyna, Biłgoraja i okolic. Codzienna praca jest zdalna: dostęp do serwera i panelu, zgłoszenia mailem, poprawki wdrażane najpierw na środowisku testowym i wypuszczane po sprawdzeniu zamówienia testowego oraz płatności. Spotkanie na miejscu ma sens w trzech sytuacjach: na starcie współpracy, przy większym wdrożeniu (migracja, zmiana szablonu, integracja z magazynem) i gdy problem siedzi w sprzęcie lub sieci w firmie, a nie w samym sklepie.
Rozmawiasz bezpośrednio z deweloperem, który wykonuje zmiany. Nie ma account managera, który przekazuje zadanie dalej i wraca z odpowiedzią po dwóch dniach. Osoba prowadząca Twój sklep wie, które moduły są niestandardowe, gdzie są nadpisane szablony i które miejsce w kodzie generuje najwięcej błędów. Drugi deweloper zna projekt na wypadek urlopu lub choroby — to zapis w umowie, nie gest dobrej woli.
Zamiast kupować te same wtyczki w każdym sklepie, piszemy własne moduły: eksport zamówień do systemu księgowego, niestandardowe statusy, integracja z firmą kurierską czy hurtownią. Płacisz raz za wdrożenie, a nie co roku za odnowienie licencji w kilku sklepach naraz. Mniej zależności oznacza też krótszą listę rzeczy, które psują się po aktualizacji PrestaShop.
Zgłoszenie wysyłasz mailem na adres podany w umowie. Dostaje numer, kategorię i priorytet: P1 to sklep nie działa albo płatności nie przechodzą — reakcja w godzinach pracy liczona w minutach; P2 to błąd z obejściem; P3 to zmiana lub drobiazg. Prace wdrożeniowe planujemy w oknie serwisowym, poza szczytem zamówień.
Szczegóły dla poszczególnych miejscowości zebraliśmy osobno: utrzymanie i opieka techniczna sklepów w Zamościu, opieka techniczna sklepów w Szczebrzeszynie oraz utrzymanie sklepów w Zwierzyńcu.
Krok 1: audyt techniczny sklepu. Przejdź listę 20 punktów. Najważniejsze z nich: wersja PHP i to, czy producent jeszcze ją wspiera, data wygaśnięcia certyfikatu SSL i czy odnowienie jest automatyczne, wersje PrestaShop lub WooCommerce oraz modułów, miejsce przechowywania kopii zapasowych i data ostatniego testu odtworzenia, działanie integracji (płatności, kurierzy, faktury, magazyn, Google Merchant), zadania cron, logi błędów, czas odpowiedzi serwera, uprawnienia użytkowników i to, czy szablon nie nadpisuje plików core. Wystarczy arkusz z kolumnami: punkt, stan, ryzyko, koszt naprawy.
Krok 2: inwentaryzacja awarii z ostatnich 6 miesięcy. Wypisz każdą awarię: datę, objaw, czas od zgłoszenia do naprawy i godziny przestoju. Potem policz koszt: godziny przestoju × średni przychód na godzinę. Przykład: 4 godziny przestoju w piątek, przy 12 zamówieniach na godzinę i średniej wartości zamówienia 180 zł, to ponad 8 tys. zł utraconej sprzedaży w jeden dzień — bez kosztu klientów, którzy już nie wrócili.
Krok 3: wybór modelu współpracy i brief. Trzy warianty są opisane niżej. Brief to jedna strona: adres sklepu, wersja systemu, lista integracji, liczba zamówień miesięcznie, kto po Twojej stronie odpowiada za sklep i co bolało najbardziej przez ostatnie pół roku.
Pierwsze spotkanie trwa 30–45 minut. Zakres: przejście listy 20 punktów, lista ryzyk w kolejności ważności i wstępny wybór modelu. Bez prezentacji sprzedażowej i bez zobowiązania do podpisania umowy.
| Model | Co wchodzi w miesiącu | Dla kogo |
|---|---|---|
| Abonament minimum | Aktualizacje, monitoring, kopie zapasowe, 2 godziny prac | Sklep z jedną integracją, kilkaset zamówień miesięcznie |
| Abonament standard | Jak minimum + SLA na P1, raport miesięczny, 6–8 godzin prac | Sklep z sezonem, kilkoma integracjami i płatnościami ratalnymi |
| Godziny na żądanie | Brak stałej opieki, rozliczenie za faktycznie przepracowane godziny | Sklep w budowie, testowy albo taki, który nie sprzedaje online |
Traktowanie hostingu jako opieki technicznej. Klient płaci abonament hostingowy i zakłada, że sklep jest „pod opieką”, choć nikt nie aktualizuje modułów ani nie sprawdza checkoutu.
Jak wykryć: Weź ostatnią fakturę od dostawcy hostingu i przeczytaj zakres usługi. Jeśli nie ma tam ani słowa o aktualizacjach aplikacji, kopie zapasowe są tylko po stronie serwera, a wsparcie kończy się na „zgłoś awarię serwera”, to nie jest opieka.
Jak naprawić: Rozdziel w umowie dwie warstwy: infrastrukturę (hosting/VPS, dostępność serwera) i aplikację (PrestaShop/WooCommerce, moduły, integracje). Dopiero suma tych dwóch warstw plus bezpieczeństwo i wydajność daje pełną opiekę.
Kopie zapasowe bez testu odtworzenia. Backup „jest”, ale nikt nigdy nie sprawdził, czy da się z niego uruchomić sklep.
Jak wykryć: Zapytaj wykonawcę, kiedy ostatnio odtwarzał kopię na środowisko testowe i czy ma z tego notatkę lub raport. Odpowiedź „backupy działają automatycznie” to sygnał ostrzegawczy.
Jak naprawić: Wpisz do umowy test odtworzenia raz na kwartał, z krótkim raportem: data, z którego backupu, ile zajął, czy zamówienia i stany magazynowe się zgadzają. Backup, którego nie odtworzyłeś, nie istnieje.
Aktualizacje w godzinach szczytu i bez środowiska testowego. Moduły wgrywane wprost na produkcję o 12:00 w poniedziałek.
Jak wykryć: Sprawdź, czy w sklepie pojawia się okno serwisowe albo czy po aktualizacji klient zgłasza błędy koszyka. Drugi sygnał: brak stagingu, czyli kopii sklepu do testów.
Jak naprawić: Ustal stałe okno serwisowe poza godzinami sprzedaży (np. wtorek 6:00–8:00), aktualizacje zawsze najpierw na stagingu, potem na produkcji, i test ścieżki zakupowej po każdej zmianie.
Umowa bez czasów reakcji i bez definicji awarii. Jest tylko „wsparcie mailowe”, więc nie wiadomo, kiedy ktoś zacznie działać.
Jak wykryć: Poszukaj w umowie zwrotów „czas reakcji”, „czas naprawy”, „awaria krytyczna”. Jeśli ich nie ma, w praktyce czas reakcji zależy od tego, kto pierwszy odbierze telefon.
Jak naprawić: Zdefiniuj trzy kategorie: awaria krytyczna (sklep nie działa, nie da się złożyć zamówienia), poważna (błąd checkoutu, płatności, dostawy) i zwykła (błąd w opisie, literówka, drobny problem w panelu). Do każdej przypisz czas reakcji i czas naprawy.
Brak dostępów po stronie klienta. Domena, serwer, panel sklepu i konta integracji są zarejestrowane na wykonawcę.
Jak wykryć: Spróbuj samodzielnie zresetować hasło do panelu hostingowego albo sprawdzić, na kogo jest zarejestrowana domena. Jeśli nie masz dostępu, zależysz od jednej firmy.
Jak naprawić: Wszystkie konta – domena, hosting, panel sklepu, płatności, kurierzy, Google Analytics – powinny być założone na dane firmy lub na firmowy e-mail. Wykonawca dostaje dostęp operacyjny, nie własność.
Ryczałt „na oko” bez listy prac i bez raportu. Klient płaci 1500 zł miesięcznie i nie wie, co dostał.
Jak wykryć: Poproś o raport z ostatniego miesiąca. Jeśli nie ma listy zmian, incydentów i czasów reakcji, to znaczy, że nikt tego nie mierzy.
Jak naprawić: Ustal rozliczenie na podstawie puli godzin z wyprzedzeniem (np. 10 h/mc) z wykazem prac w raporcie. Nadwyżkę godzin rozliczasz według stawki godzinowej zapisanej w umowie.
Opierają się na czterech warstwach: aplikacji, serwerze, integracjach oraz bezpieczeństwie z kopiami zapasowymi – dopiero razem tworzą opiekę, a nie tylko hosting. W umowie muszą być czasy reakcji i naprawy, kategorie awarii, retencja kopii oraz test odtworzenia raz na kwartał. Ceny w Józefowie i okolicach zaczynają się od 250–600 zł netto miesięcznie za pakiet podstawowy i rosną wraz z liczbą integracji oraz stanem technicznym sklepu. Najważniejsze to porównywać zakres i raporty, a nie samą kwotę abonamentu.
Nie. Hosting odpowiada za warstwę infrastruktury – serwer, dostępność, zasoby. Opieka techniczna obejmuje dodatkowo aplikację (PrestaShop lub WooCommerce), moduły, integracje z kurierami i płatnościami, bezpieczeństwo oraz kopie zapasowe. Możesz mieć świetny hosting i sklep, w którym od pół roku nikt nie zaktualizował modułu płatności.
Pakiet podstawowy to zwykle 250–600 zł netto miesięcznie i obejmuje aktualizacje, monitoring oraz kopie zapasowe. Standard z obsługą integracji i poprawkami funkcjonalnymi to 800–2000 zł netto miesięcznie. Sklepy z własnymi modułami, niestandardowym motywem i integracją ERP startują od 2500 zł netto miesięcznie. Prace poza abonamentem rozliczane są stawkowo, najczęściej 120–250 zł netto za godzinę.
Możesz, jeśli masz czas i podstawy techniczne. Policz jednak realnie: aktualizacja modułów, sprawdzenie ścieżki zakupowej i reakcja na awarię to zwykle kilka godzin miesięcznie, a przy większym sklepie więcej. Największy koszt to nie sama aktualizacja, a sytuacja, w której sklep nie działa w środku sezonu, a Ty nie wiesz, od czego zacząć.
Dla awarii krytycznej, czyli braku możliwości złożenia i opłacenia zamówienia, sensowny czas reakcji to około 1 godziny w godzinach pracy, a naprawa do 8 godzin roboczych. Dla awarii poważnej (błąd naliczania dostawy, pojedyncza metoda płatności) to zwykle kilka godzin. Dla zwykłych zgłoszeń – do 2 dni roboczych. Te wartości muszą być zapisane w umowie, inaczej są tylko deklaracją.
Zakres prac jest taki sam, bo zależy od technologii i liczby integracji, a nie od kodu pocztowego. Różnice dotyczą głównie organizacji: dojazd na miejsce, dostępność w godzinach pracy, kontakt z Twoim biurem. Praca przy sklepie i tak odbywa się zdalnie na serwerze, więc porównuj zakres i czasy reakcji, a nie odległość. Przykłady zakresu dla innych miast opisujemy w materiałach o opiece technicznej sklepów w Zamościu i w Zwierzyńcu.
To podnosi koszt opieki, bo część modułów nie ma już wsparcia, a łatki bezpieczeństwa nie są wydawane. W praktyce trzeba albo zaplanować migrację, albo liczyć się z wyższą stawką za godziny pracy i ograniczoną odpowiedzialnością za niektóre funkcje. Zakres wsparcia dla poszczególnych wersji znajdziesz w dokumentacji dla deweloperów PrestaShop.
Zwykle nie. Abonament pokrywa utrzymanie, czyli aktualizacje, monitoring, bezpieczeństwo, kopie i poprawki błędów. Nowe funkcje, zmiany wyglądu i nowe integracje to prace rozwojowe rozliczane za godzinę albo wyceniane osobno. Warto, żeby umowa jasno rozdzielała te dwie kategorie, bo to najczęstsze źródło nieporozumień przy fakturze.
Jeśli chcesz wiedzieć, ile realnie kosztowałaby opieka nad Twoim sklepem, wyślij nam adres sklepu i listę integracji – przygotujemy zakres i wycenę na podstawie pomiaru, a nie „na oko”. Możesz też najpierw porównać, jak wygląda to w innych miastach, np. utrzymanie sklepów w Szczebrzeszynie.