DropDigital to polska firma technologiczna zajmująca się wdrożeniami e-commerce i web developmentem. Pracujemy z MŚP, firmami B2B sprzedającymi online oraz przedsiębiorcami, którzy migrują z jednej platformy na drugą. Działamy z Zamościa i Lublina, a realizacje prowadzimy także zdalnie w całej Polsce. Pracujesz bezpośrednio z deweloperem, który pisze kod, bez pośredników i account managerów przepisujących maile. Poniżej odpowiadamy na pytania organizacyjne: ile to kosztuje, jak wygląda proces i czego pilnować, żeby wdrożenie nie wymknęło się z budżetu.
DropDigital to polska firma technologiczna zajmująca się wdrożeniami e-commerce i web developmentem, czyli budową i utrzymaniem sklepów oraz stron, które mają pracować na konkretnych liczbach: konwersji, czasie ładowania, liczbie zamówień.
Nie jesteśmy agencją pośredniczącą. Nie ma tu account managera, który przepisuje maile do podwykonawcy. Rozmawiasz bezpośrednio z osobą, która pisze kod i odpowiada za wdrożenie. To skraca drogę od pytania „da się inaczej liczyć rabaty dla klientów B2B?” do działającego rozwiązania — bez dwóch tygodni na brief i przepisywanie wymagań.
Pracujemy z trzema grupami klientów:
Działamy z Zamościa i Lublina, obsługujemy firmy z Lubelszczyzny i Podkarpacia, a realizacje prowadzimy też zdalnie w całej Polsce. Wdrożenie, migracja i utrzymanie nie wymagają wizyt na miejscu — potrzebny jest dostęp do serwera, repozytorium i sklepu.
Dwie rzeczy wyróżniają nas w praktyce. Piszemy własne moduły, gdy gotowy moduł z marketplace kosztuje 300 zł, a potem trzy dni pracy idą na obchodzenie jego ograniczeń. I dajemy jasne SLA: w pakiecie opieki zapisujemy czas reakcji na zgłoszenie, okno serwisowe oraz definicję incydentu krytycznego (sklep nie przyjmuje zamówień) i zwykłego zadania. Dokładny przebieg prac po stronie stron i sklepów opisujemy w materiale DropDigital strony internetowe: proces, koszty, checklista.
Zakres mamy zamknięty w kilku obszarach. Poniżej pełna lista w jednym miejscu, żebyś nie musiał składać jej z podstron.
| Obszar | Co konkretnie robimy | Typowy zakres prac |
|---|---|---|
| PrestaShop — wdrożenia i migracje | Sklep od zera na 8.x, przenosiny z 1.6/1.7 do 8.x, szablony, moduły płatności i kurierów, import katalogu, wielojęzyczność | 80–250 h, migracja 40–120 h |
| WooCommerce | Wdrożenia, przebudowa szablonu, optymalizacja koszyka i checkoutu, integracje z magazynem, fakturowaniem i płatnościami | 60–180 h |
| WordPress | Strony firmowe, serwisy B2B, katalogi produktów bez koszyka, blogi, witryny wielojęzyczne | 30–120 h |
| Własne moduły i wtyczki | Kalkulatory B2B, indywidualne progi rabatowe, eksport zamówień do ERP lub Subiekta, niestandardowe formularze i panele w back office | 15–80 h za moduł, po estymacji |
| Serwery i VPS | Nginx, PHP-FPM, Redis, SSL, backupy, monitoring, przenosiny hostingu, środowisko staging | 8–40 h + opieka |
| SEO techniczne | Dane strukturalne, canonical, sitemap.xml, kontrola indeksacji, przekierowania 301 po migracji | 10–40 h |
| Wydajność | Core Web Vitals: LCP, INP, CLS — kompresja obrazów, cache, krytyczny CSS, ograniczenie skryptów zewnętrznych | 10–30 h |
| Opieka techniczna | Aktualizacje rdzenia i modułów, kopie zapasowe, monitoring, godziny serwisowe | abonament + godziny |
Zasada jest jedna: wycena = stawka godzinowa × liczba godzin z estymacji. Nie ma pozycji „inne” ani kosztów, które pojawiają się dopiero na fakturze. Estymacja jest rozbita na etapy, więc widzisz, ile godzin pochłania import katalogu, ile konfiguracja płatności, a ile szablon.
| Zakres | Orientacyjna liczba godzin | Od czego zależy |
|---|---|---|
| Wdrożenie PrestaShop 8.x | 80–250 h | liczba integracji, szablon standardowy czy autorski, wielojęzyczność, wielkość importu katalogu |
| Wdrożenie WooCommerce | 60–180 h | zakres wtyczek, przebudowa checkoutu, integracje magazynowe i księgowe |
| Migracja PrestaShop 1.6/1.7 → 8.x | 40–120 h | moduły do przepisania, dane historyczne, przekierowania 301, SEO |
| Migracja z platformy abonamentowej do WooCommerce | 50–140 h | struktura danych, sposób eksportu, subskrypcje i strefy wysyłki |
Wdrożenie dzielimy na siedem etapów. Każdy kończy się plikiem albo linkiem, który możesz obejrzeć i zaakceptować — nie ma etapu „pracujemy i damy znać”.
Twoja rola: dostępy (panel sklepu, FTP/SSH, API do ERP, dokumentacja kuriera), decyzje o zakresie i akceptacje. Potrzebujemy ich w trzech momentach: zakres, staging, start. Każdy dzień zwłoki z Twojej strony przesuwa start o ten sam dzień.
Jedna osoba kontaktowa po naszej stronie to deweloper, który pisze kod. Piszesz do niego, nie do pośrednika, co skraca ustalenia techniczne z dni do minut. Jak to wygląda przy wdrożeniu zwykłej strony firmowej, opisaliśmy w materiale o procesie wdrożenia strony internetowej krok po kroku.
Zanim cokolwiek wycenimy, chcemy usłyszeć objaw, nie nazwę usługi. „Potrzebuję optymalizacji” znaczy zwykle coś innego niż „potrzebuję integracji”. Poniżej najczęstsze zgłoszenia z projektów MŚP i to, co realnie za nimi stoi.
Godziny w tabeli to widełki orientacyjne, nie oferta — zakres domykamy po audycie. Część rzeczy robimy sami: audyt zapytań do bazy, konfigurację cache, kod modułu integracyjnego, testy na stagingu. Od Ciebie potrzebujemy dostępów (panel sklepu, hosting, panel operatora płatności, konto kurierskie), danych testowych i decyzji o zakresie. Jeśli problem leży po stronie ERP albo księgowości, potrzebujemy jednej osoby po tamtej stronie, która potwierdzi mapowanie pól.
W pierwszej wiadomości napisz cztery rzeczy: adres sklepu, platformę i wersję, konkretny objaw z przykładem (np. numer zamówienia, przy którym nie poszła płatność) i oczekiwany termin. Hasła prześlij przez menedżera haseł, nie mailem. Jak liczymy wycenę i z czego składa się budżet wdrożenia, rozpisaliśmy w sekcji cennik, wdrożenie i integracje.
Osobno wydajność frontu: progi LCP poniżej 2,5 s i INP poniżej 200 ms, opisane w dokumentacji Core Web Vitals (web.dev), mierzy się na telefonie i na realnym łączu, a nie na biurkowym komputerze w biurze.
| Problem zgłaszany przez klienta | Co robimy | Orientacyjny czas |
|---|---|---|
| Sklep zwalnia po przekroczeniu ok. 1000 zamówień | Audyt zapytań do bazy, indeksy, cache, przegląd modułów | 20–60 h |
| Klienci porzucają koszyk, bo nie ma BLIK | Wdrożenie płatności online: BLIK, przelewy, karty, poprawne webhooki i zwroty | 8–20 h |
| Zamówienia z ERP przepisywane ręcznie do sklepu | Integracja sklepu z ERP: produkty, stany, zamówienia, faktury | 40–120 h |
| Brak potwierdzenia nadania w InPost | Integracja kurierska: etykiety, statusy przesyłek, punkt odbioru, zwroty | 12–40 h |
| Sklep na przestarzałej wersji z ryzykiem CVE | Kopia zapasowa, aktualizacja na stagingu, przegląd modułów, dopiero potem produkcja | 10–30 h |
| Kategoria ładuje się 4 s na telefonie | Optymalizacja LCP i INP: obrazy, JS, zapytania startowe | 15–40 h |
Integracje to obszar, w którym wdrożenia najczęściej się wymykają — bo błąd widać dopiero po tygodniu, gdy stany magazynowe przestają się zgadzać. Dlatego każdą integrację zaczynamy od mapowania, nie od kodu.
ERP. Ustalamy, które pole ERP odpowiada któremu polu sklepu: SKU i EAN jako klucz produktu, ceny netto i brutto, VAT, jednostki miary, kategorie, stany w poszczególnych magazynach. Potem kierunek synchronizacji. Najczęściej ERP jest źródłem prawdy dla cen i stanów, a sklep dla zamówień; zamówienie trafia do ERP, a po wystawieniu faktury wraca numer dokumentu. Synchronizacja dwustronna brzmi dobrze, ale bez reguł rozstrzygania konfliktów (kto wygrywa, gdy cena zmieniła się po obu stronach) kończy się nadpisywaniem danych.
Płatności. Przed wdrożeniem sprawdzamy webhooki: czy przychodzą z podpisem, czy docierają po zmianie statusu i czy nie gubią się przy ponowieniach. Testujemy wszystkie statusy — nowe, autoryzowane, opłacone, anulowane, zwrócone — oraz zwroty częściowe. BLIK i płatności ratalne mają inne limity i inną ścieżkę potwierdzenia niż zwykły przelew.
Kurierzy. Generowanie etykiet, statusy przesyłek, wybór punktu odbioru w koszyku, zwroty. Całą ścieżkę przechodzimy na zamówieniu testowym przed startem: zamówienie → płatność → etykieta → zmiana statusu → zwrot.
Pracujesz z nami na jednym kanale i z deweloperem, który pisze kod — w PrestaShop punktem wyjścia jest dokumentacja deweloperska PrestaShop (webservice, struktura modułów).
| Obszar | Co ustalamy przed startem | Typowa pułapka |
|---|---|---|
| ERP — produkty i stany | Mapowanie pól, kierunek synchronizacji, częstotliwość (webhook vs cron), klucz produktu | Brak jednoznacznego klucza → duplikaty produktów po drugim przebiegu synchronizacji |
| ERP — zamówienia i faktury | Kto tworzy dokument, co wraca do sklepu, obsługa anulowań | Zamówienie powstaje w ERP dwa razy po ponowieniu webhooka |
| Płatności online | Webhooki, statusy, zwroty pełne i częściowe, ponowienie nieudanej płatności | Brak webhooka → zamówienie wisi jako oczekujące, mimo że pieniądze wpłynęły |
| Kurierzy (InPost, DPD, DHL) | Etykiety, statusy przesyłek, punkt odbioru, zwroty, dane o gabarytach i wadze | Limit API przy wysyłce partii paczek i brak kolejki ponowień |
| Utrzymanie integracji | Logowanie błędów, alerty, kopia danych przed każdą aktualizacją | Cichy błąd bez logu → rozjazd stanów wychodzi dopiero po kilku dniach |
Migrację zaczynamy od inwentaryzacji, nie od importu. W praktyce przenosimy siedem grup danych: produkty (SKU, ceny, stany, warianty, atrybuty, zdjęcia), kategorie z drzewem i przypisaniami, klientów (hasła tylko jako hashe — nigdy w postaci jawnej), zamówienia z historią (statusy, płatności, faktury), adresy URL, treści (strony CMS, opisy kategorii) oraz uprawnienia pracowników. Osobno przenosimy meta tytuły i opisy — bez nich część stron startuje od zera. Struktura tabel i sposoby importu w PrestaShop są opisane w dokumentacji dla deweloperów PrestaShop.
Pułapka numer jeden: brak przekierowań 301. Jeśli stary adres /kurtka-zimowa-meska-xxx zniknie, a produkt wyląduje pod /kurtki/zimowe/meska, Google dostaje 404. Efekt widzimy zwykle po 2–6 tygodniach: spadek ruchu organicznego o 20–60% zależnie od tego, ile URL-i miało ruch. Kolejność działania: eksport adresów z Search Console (Indeksowanie → Pliki), crawl starego sklepu (Screaming Frog wystarczy), zrzut listy nowych URL-i, potem mapa w CSV stary → nowy i wdrożenie przez .htaccess lub moduł przekierowań. Zasada: mapujemy także adresy bez ruchu — kosztuje to minuty, a ratuje długi ogon.
Kopia zapasowa przed pierwszym importem. Przed czymkolwiek robimy pełny dump bazy, archiwum plików i eksport konfiguracji. To nie formalność: import 12 tys. produktów z błędnym mapowaniem atrybutów potrafi nadpisać ceny w 3 minuty. Bez punktu przywracania nie ma drogi powrotnej, jest tylko ręczne poprawianie.
Staging i test na koniec. Wszystko testujemy na kopii produkcji: import, przekierowania, koszyk, mail po zamówieniu, faktura, płatność w trybie piaskownicy. Ostatni krok to zamówienie testowe od A do Z na produkcji — po nim dopiero wyłączamy stary sklep.
| Co migrujemy | Na co uważać | Kolejność |
|---|---|---|
| Produkty i warianty | Powiązania z magazynem po SKU, nie po ID | 1 |
| Kategorie i drzewo | Zmiana struktury zmienia URL-e i okruszki | 2 |
| Klienci | Hasła wyłącznie jako hashe; test logowania na 5 kontach | 3 |
| Zamówienia i historia | Statusy i numeracja faktur muszą zostać spójne | 4 |
| Adresy URL | Mapa 301 gotowa przed startem, nie po | 5 |
| Treści i SEO | Meta, opisy kategorii, alt-y zdjęć | 6 |
| Uprawnienia pracowników | Role i zakresy dostępu do modułów | 7 |
Opieka to nie „będziemy mieć oko na sklep”. To lista czynności z częstotliwością i osoba, która za nie odpowiada. W standardowym pakiecie mamy: aktualizacje bezpieczeństwa rdzenia, modułów i motywu (mniejsze raz w miesiącu, krytyczne łaty w ciągu 24–72 h od publikacji), kopie zapasowe — baza codziennie, pliki raz w tygodniu, retencja 30 dni, monitoring dostępności z sondą co 1–5 minut, reagowanie na incydenty oraz drobne poprawki w ramach pakietu godzin (typowo 2–4 h miesięcznie).
Parametry SLA ustalamy na piśmie, bo bez nich „szybko” znaczy wszystko i nic. Trzy liczby do uzgodnienia: czas reakcji (przyjęcie zgłoszenia i potwierdzenie, że je widzimy), czas naprawy (od potwierdzenia do działającego rozwiązania lub obejścia) i okno serwisowe, czyli godziny, w których te czasy obowiązują. Dla sklepu z 300 zamówieniami miesięcznie realny punkt startu to reakcja do 4 h w godzinach pracy i 24 h dla spraw drobnych.
Jedno miejsce na wszystkie zgłoszenia. Helpdesk albo wspólna skrzynka z numerem zgłoszenia. Zgłoszenie wysłane na Messengera do dewelopera o 22:00 nie ma wątku, priorytetu ani historii — przy dwóch osobach po stronie klienta to gwarantowany chaos.
Próg, od którego opieka nie wystarcza: nowa funkcja, nowa integracja (płatności, ERP, marketplace), przebudowa szablonu, migracja, zmiana logiki koszyka lub rabatów. To nie jest „poprawka” — wyceniamy je osobno, z estymacją godzin przed startem, żeby nikt nie pracował na otwartym budżecie.
| Klasa zdarzenia | Przykład | Czas reakcji | Czas naprawy |
|---|---|---|---|
| P1 – krytyczne | Sklep nie działa, padły płatności, zamówienia się nie zapisują | do 1 h (4 h poza godzinami pracy) | do 4 h od potwierdzenia |
| P2 – poważne | Błąd koszyka, niedziałająca metoda dostawy, wysypany import | do 4 h | 1 dzień roboczy |
| P3 – zwykłe | Błąd wyświetlania, literówka, problem z jednym produktem | do 24 h | 3–5 dni roboczych |
| P4 – drobne i rozwojowe | Zmiana treści, banner, poprawka w szablonie | do 48 h | wg kolejki, z pakietu godzin lub osobnej wyceny |
Do wyceny nie potrzebujemy briefu na 20 stron. Wystarczy sześć informacji: adres sklepu (nawet jeśli ma status „w budowie”), platforma i wersja (np. PrestaShop 1.7.8, WooCommerce 8.x), zakres — co ma działać po wdrożeniu, termin i jego sztywność, istniejące integracje (płatności, kurierzy, Subiekt/ERP, księgowość, marketplace) oraz informacja, kto po Waszej stronie podejmuje decyzje. Jeśli nie znacie wersji — nie szkodzi, sprawdzimy to sami.
Co dzieje się po kontakcie: 1) rozmowa lub audyt wstępny (30–60 minut) — ustalamy zakres i wyłapujemy ryzyka, np. brak przekierowań albo integrację, która nie ma API. 2) Estymacja godzin rozbita na moduły, żeby było widać, co waży najwięcej. 3) Oferta z podziałem na etapy i płatnościami przypisanymi do etapów, nie do „startu i końca”. Dostajecie też listę rzeczy, których świadomie nie robimy w pierwszej iteracji.
Szczegóły naszej kolejności prac opisuje artykuł DropDigital strony internetowe: proces, koszty, checklista, a widełki budżetowe i zakres integracji znajdziesz w DropDigital strony internetowe: cennik, wdrożenie, integracje.
Działamy z Zamościa i Lublina, więc jeśli jesteś z tego regionu, możemy spotkać się na miejscu — u Was w firmie albo u nas, z konkretną listą pytań i dostępem do sklepu. Firmy z reszty Polski prowadzimy w pełni zdalnie: wideorozmowa, wspólny helpdesk i ten sam deweloper od pierwszego dnia do przekazania.
Wycena "na oko", bez estymacji w godzinach i rozbicia na etapy.
Jak wykryć: W ofercie widzisz jedną kwotę końcową i opis typu "wdrożenie sklepu", bez liczby godzin, bez listy pozycji ani założeń zakresowych.
Jak naprawić: Poproś o estymację: lista zadań, liczba godzin przy każdym, stawka godzinowa i założenia (np. ile integracji, ile języków, czyj szablon). Dopiero na tej podstawie porównuj oferty między firmami.
Prace prowadzone bezpośrednio na produkcji, bez środowiska testowego.
Jak wykryć: Wykonawca prosi o dostęp FTP lub panel do działającego sklepu i tam testuje zmiany, albo wdraża poprawki w godzinach sprzedaży.
Jak naprawić: Wymagaj stagingu, czyli kopii sklepu na osobnym adresie, z osobną bazą danych. Zmiany idą najpierw na staging, potem na produkcję w oknie serwisowym.
Zakres ustalany wyłącznie w mailach, bez dokumentu i procedury zmian.
Jak wykryć: Nie ma dokumentu zakresu. Po dwóch tygodniach nikt nie pamięta, czy wielojęzyczność była w cenie, a nowe pomysły dochodzą w kolejnych wątkach.
Jak naprawić: Jeden dokument zakresu z datą i wersją, do którego dopisuje się zmiany na zasadzie change request: opis, wpływ na godziny, akceptacja klienta przed startem prac.
Migracja danych zaplanowana na sam koniec projektu.
Jak wykryć: Do momentu startu nikt nie sprawdził, czy zamówienia, klienci i adresy zbudują się poprawnie w nowym systemie. Import robi się "w nocy przed startem".
Jak naprawić: Import na staging zrób minimum dwa tygodnie przed startem. Sprawdź mapowanie pól, statusy zamówień, konta klientów i historię płatności. Poproś o raport błędów importu.
Brak ustalonego SLA i jasnego kanału zgłaszania awarii.
Jak wykryć: Nie wiesz, w jakim czasie ktoś zareaguje, gdy sklep przestanie przyjmować zamówienia, ani czy naprawa jest w pakiecie, czy płatna ekstra.
Jak naprawić: Ustal przed startem: kanał zgłoszeń, godziny reakcji w dni robocze, czas reakcji na awarie krytyczne, zakres poprawkowy w cenie i stawki za prace poza pakietem.
Każda funkcja dokładana kolejną płatną wtyczką z marketplace.
Jak wykryć: Liczba rozszerzeń rośnie z każdą rozmową, pojawiają się konflikty po aktualizacjach, a roczne koszty licencji nie są nigdzie zsumowane.
Jak naprawić: Policz koszt licencji w horyzoncie 2-3 lat i porównaj z modułem pisanym na zamówienie. Niestandardowy moduł bywa droższy na starcie, ale nie blokuje aktualizacji i nie mnoży punktów awarii.
Wdrożenie e-commerce w DropDigital da się policzyć i zaplanować — nie musi być pudełkiem niespodzianek. Kluczowe są trzy rzeczy: dokument zakresu z estymacją godzinową, środowisko testowe z wcześniejszym importem danych oraz jasno opisana opieka po starcie z czasami reakcji. Jeśli którykolwiek z tych elementów nie pojawia się w ofercie, to znak, że ryzyko projektu zostało przeniesione na Ciebie. Szczegóły procesu i warianty wyceny znajdziesz w naszych materiałach o procesie wdrożenia i o cenniku i integracjach.
Nie mamy jednego cennika, bo cena wynika z liczby godzin potrzebnych na realizację. Orientacyjnie: wdrożenie PrestaShop to około 80-250 godzin, WooCommerce 60-180 godzin, a migracja z jednej platformy na drugą 40-120 godzin. Dopiero po warsztacie i estymacji podajemy konkretną kwotę z rozbiciem na pozycje.
Wdrożenie o ustalonym zakresie wyceniamy ryczałtowo — wtedy ryzyko przekroczenia godzin bierzemy na siebie. Prace rozwojowe, poprawki po starcie i zadania, których zakresu nie da się domknąć z góry, rozliczamy godzinowo według stawki z umowy. Zasada jest jedna: wycena = stawka × liczba godzin z estymacji, bez ukrytych pozycji.
Liczba integracji zewnętrznych, niestandardowy moduł lub wtyczka, import danych z niespójnego źródła, wielojęzyczność i sklep na autorskim szablonie. Każda z tych rzeczy dodaje godziny, których nie widać w prostym opisie "zrobić sklep". Dlatego zbieramy je na warsztacie i wpisujemy do dokumentu zakresu przed startem.
Tak, migracje między wersjami PrestaShop to jedna z naszych standardowych usług. W praktyce projekt zaczyna się od inwentaryzacji modułów i nadpisań szablonu, bo to one najczęściej blokują płynną aktualizację. Punktem odniesienia przy planowaniu jest dokumentacja deweloperska PrestaShop: devdocs.prestashop-project.org.
Tak. Baza to Zamość, Lublin i okolice, ale realizacje prowadzimy zdalnie w całej Polsce. Warsztat początkowy i przekazanie projektu robimy online, a cała dokumentacja i komunikacja i tak trafia do Ciebie na piśmie. Odległość ma znaczenie głównie przy projektach, które wymagają częstych spotkań na miejscu.
Tak, i często wychodzi to taniej w dłuższym okresie. Jeśli potrzebujesz funkcji, którą łatwo zastąpić modułem pisanym pod Twój proces, liczymy koszt licencji na 2-3 lata i porównujemy z wyceną modułu. Niestandardowy kod nie zniknie przy aktualizacji i nie wejdzie w konflikt z dziesięcioma innymi rozszerzeniami.
Typowo: aktualizacje systemu i modułów, kopie zapasowe, monitoring dostępności, reakcja na awarie w ustalonych godzinach oraz pula drobnych prac poprawkowych. Nowe funkcje i rozwój sklepu są osobnym zakresem, rozliczanym godzinowo. Granicę między pakietem a pracami dodatkowymi ustalamy przed startem, żeby nie było niedomówień przy pierwszej fakturze.
Jeśli chcesz wiedzieć, ile godzin realnie zajmie Twój projekt, napisz do nas z krótkim opisem zakresu — odpowiemy estymacją, nie ogólnikami.