W DropDigital strony internetowe to wdrożenie techniczne, a nie wizytówka z szablonu — dlatego praca ma etapy, godziny i punkt odbioru. Zanim wyślesz zapytanie, warto wiedzieć, jak ten proces wygląda po naszej stronie: co robimy, kiedy potrzebujemy Twojej decyzji i ile to realnie trwa. Poniżej rozkładamy wdrożenie na 7 etapów, podajemy widełki budżetowe liczone w godzinach i checklistę odbioru. To materiał organizacyjny — szczegóły techniczne i decyzje o platformie opisujemy w osobnych sekcjach.
W DropDigital strona internetowa to wdrożenie techniczne, a nie gotowy motyw z marketplace. Pierwsza decyzja dotyczy platformy, bo ona przesądza o koszcie utrzymania i tempie rozwoju na najbliższe 2–4 lata:
Zakres jednej realizacji zwykle obejmuje: architekturę informacji (mapa URL, struktura kategorii, przekierowania 301), projekt graficzny, development motywu i modułów, integracje (płatności, kurierzy, faktury, ERP), testy, publikację oraz opiekę po starcie. Wydajność traktujemy jako element architektury, nie jako dodatek na koniec – fundament opisujemy w materiale Web design i development: 10 elementów szybszej strony.
Pracujemy z MŚP i B2B w Polsce, w tym z firmami z Zamościa, Lublina i całego regionu – usługami, produkcją i dystrybucją. Praca odbywa się zdalnie, z warsztatami online i rozliczaniem godzin, więc nie musisz wozić dokumentów przez pół województwa.
Proces jest stały, niezależnie od tego, czy robimy stronę firmową na WordPressie, czy sklep na PrestaShop. Zmienia się tylko liczba godzin w etapach 3–6.
| Etap | Czas (roboczogodziny) | Decyzja po Twojej stronie |
|---|---|---|
| 1. Brief techniczny | 2–4 h | cele, lista funkcji, integracje, budżet |
| 2. Wycena godzinowa | 2–6 h | akceptacja zakresu i stawki |
| 3. Architektura informacji i wireframe | 8–20 h | akceptacja struktury URL i układu podstron |
| 4. Projekt graficzny | 12–40 h | akceptacja makiety (2 rundy poprawek w cenie) |
| 5. Development | 40–120 h | dostarczenie treści, zdjęć, dostępów do domeny i DNS |
| 6. Testy i QA | 8–24 h | testy akceptacyjne po Twojej stronie (UAT) |
| 7. Publikacja i przekazanie dostępów | 4–8 h | wybór daty startu, potwierdzenie przekierowań |
Najczęstszyhamulec to treści. Każdy tydzień zwłoki z tekstami i zdjęciami przesuwa start developmentu o tydzień – nie da się zbudować szablonu pod treści, których nie ma. To samo dotyczy dostępu do DNS: jeśli rejestrator jest na czyimś prywatnym koncie, publikacja stoi.
Definition of Done przed odbiorem: formularze wysyłają i zapisują zgłoszenia, płatności przetestowane w trybie testowym i produkcyjnym, 404 i przekierowania 301 działają, sitemap.xml i robots.txt są poprawne, strona przechodzi testy wydajności (o tym, co realnie waży na wyniku, piszemy w Jak przyspieszyć ładowanie strony: 9 błyskawicznych trików), kopie zapasowe się wykonują, a Ty masz dostępy do panelu, hostingu i rejestratora domeny. Odbieramy dopiero ten zakres – lista jest spisywana przed startem, żeby nie było sporów na koniec.
Nie publikujemy cennika „za stronę”, bo dwie firmy opisujące potrzebę tak samo potrafią potrzebować 35 h i 140 h. Wycena to liczba godzin × stawka godzinowa ustalona na start projektu i zapisana w umowie. Stawka nie zmienia się w trakcie – zmienia się wyłącznie zakres i zawsze po Twojej pisemnej akceptacji. Dzięki temu porównasz oferty po godzinach, a nie po hasłach.
| Typ realizacji | Godziny | Co zwykle zawiera |
|---|---|---|
| Strona firmowa (5–10 podstron) | 30–60 h | architektura, projekt, dev motywu, formularze, SEO techniczne, wdrożenie |
| Rozbudowany serwis / portal treściowy | 80–160 h | wiele szablonów, wyszukiwarka, filtry, wielojęzyczność, migracja treści |
| Sklep (WooCommerce / PrestaShop) | 120–300 h | katalog, koszyk, płatności, kurierzy, faktury, integracja ERP, migracja produktów |
Podział budżetu wygląda podobnie w każdym projekcie: architektura i brief ok. 10%, projekt graficzny 15–20%, development 50–60%, testy i wdrożenie 10–15%. Opieka po starcie to osobna pozycja rozliczana miesięcznie (aktualizacje, backupy, monitoring, drobne poprawki).
Koszt podnoszą: integracja z ERP (20–60 h zależnie od tego, czy system ma API, czy trzeba pracować na eksporcie plików), każda wersja językowa (+10–15% godzin), niestandardowe moduły (15–40 h każdy) oraz migracja treści – 500 produktów to zwykle 10–20 h, 5000 to 60–120 h.
Własny moduł bywa tańszy niż łańcuch płatnych wtyczek. Przykład: trzy wtyczki po 150 USD rocznie to 450 USD/rok, czyli ok. 1350 USD w trzy lata (przy kursie blisko 4 zł/USD ponad 5000 zł), plus ryzyko podwyżek i konfliktów po aktualizacjach. Moduł pisany pod Twoje procesy to 25–40 h jednorazowo, bez licencji i bez uzależnienia od dostawcy. Przy krótkim horyzoncie wtyczka bywa tańsza – przy 3 latach i kilku rozszerzeniach rachunek przechyla się na kod własny.
Platformę wybiera się na podstawie trzech liczb: ile masz SKU (z wariantami), w ilu językach sprzedajesz i czy kupującym jest firma, czy konsument. Argument „bo konkurencja ma WooCommerce” nie jest kryterium.
Praktyczne progi, które sprawdzają się w projektach:
Hosting idzie w parze z platformą: dobry hosting managed pod WooCommerce to typowo 60–250 zł/mies., pod PrestaShop zwykle VPS 120–400 zł/mies. plus administracja – aktualizacje, backupy, monitoring.
Kiedy nie potrzebujesz sklepu wcale: gdy większość zamówień to zapytania ofertowe z ceną ustalaną indywidualnie, nie chcesz płatności online i nie prowadzisz stanów magazynowych. Strona z formularzem zapytania, wysyłką leada do CRM (webhook lub API) i kilkoma landingami kosztuje mniej w budowie, a przede wszystkim mniej w utrzymaniu – nie ma aktualizacji sklepu, konfliktów wtyczek i zgodności podatkowych.
Trzecia zmienna to dostępność deweloperów. WordPress i WooCommerce to w Polsce najszersza grupa wykonawców. PrestaShop – węższa: przed podpisaniem umowy zapytaj, czy wykonawca pracuje na dokumentacji dla deweloperów PrestaShop i czy ma wdrożenia na Twojej wersji (1.7 vs 8.x). Jeśli nie, każda zmiana będzie kosztować więcej i trwać dłużej.
| Kryterium | WordPress + WooCommerce | PrestaShop |
|---|---|---|
| Liczba SKU (z wariantami) | Komfort do ok. 1000–2000 SKU; przy 5000+ potrzebny cache obiektowy i optymalizacja zapytań | Lepsza tolerancja na duże katalogi i kombinacje; przy 50 000+ SKU i tak osobna warstwa wyszukiwania |
| Wielojęzyczność | Wtyczka (licencja roczna), osobne wpisy dla każdego języka | Natywnie: jeden produkt, wiele tłumaczeń i walut |
| B2B (ceny indywidualne, limity kredytowe) | Ceny per grupa i limity kredytowe przez wtyczki lub custom | Grupy klientów i ceny per grupa natywnie; limity kredytowe i odroczone płatności przez moduły |
| Koszt hostingu | Managed 60–250 zł/mies. | VPS 120–400 zł/mies. plus koszt administracji |
| Koszt rozwoju (roboczogodziny) | Prosty sklep ok. 60–150 h | Ok. 120–300 h przy B2B i wielojęzyczności |
| Dostępność deweloperów w Polsce | Najszersza grupa wykonawców | Węższa, ale dokumentacja i rynek wtórny istnieją |
Trzy metryki mają jasne progi: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1. Liczy się je z 75. percentyla realnych sesji – trzy czwarte użytkowników ma doświadczyć tego poziomu lub lepszego. W praktyce: przy LCP 4 s klient czeka cztery sekundy na baner; przy INP 600 ms klika „Dodaj do koszyka”, przez pół sekundy nic się nie dzieje i klika drugi raz; przy CLS 0,3 przycisk przesuwa się pod palcem i klient trafia w link obok. Definicje znajdziesz w dokumentacji Web Vitals.
Najczęstsi zabójcy wydajności na WordPressie:
VPS lub serwer dedykowany ma sens, gdy: baza ma ponad ~1 GB, sklep przekracza 1000 SKU, ceny i koszyk liczą się dla zalogowanych użytkowników, ruch rośnie skokowo (kampanie), a hosting współdzielony nie daje Redis ani własnej konfiguracji PHP-FPM. Nie ma sensu przy stronie firmowej z 5 podstronami i 200 odsłonami dziennie – tam lepiej wydać te pieniądze na dobrze skonfigurowany hosting managed i CDN. Konkretne ustawienia opisujemy w tekście o przyspieszaniu ładowania strony.
Pomiar: PageSpeed Insights daje lab (Lighthouse) i dane terenowe z CrUX; Lighthouse w DevTools to wyłącznie lab; Search Console, raport Core Web Vitals, to dane rzeczywiste z ostatnich 28 dni. Lab służy do diagnozy (co poprawić), field do oceny (czy użytkownicy odczuli różnicę). Testowanie wyłącznie na szybkim łączu i mocnym laptopie to najczęstszy błąd.
| Metryka | Próg dobry | Co odczuwa użytkownik | Typowa przyczyna |
|---|---|---|---|
| LCP | poniżej 2,5 s | Treść pojawia się szybko | Ciężki obraz hero, brak cache, wolny TTFB |
| INP | poniżej 200 ms | Klik działa natychmiast | Zbyt wiele skryptów, brak rozdzielenia ładowania JS |
| CLS | poniżej 0,1 | Elementy nie uciekają pod palcem | Brak width/height, podmiana fontu, banery wstawiane JS-em |
SEO techniczne robi się na etapie budowy. Dokładanie go po roku kosztuje więcej, bo wiąże się ze zmianą adresów i przekierowaniami.
Czego nie robić: masowo generować strony tagów i pustych kategorii. Setki cienkich adresów zjadają budżet indeksacji – robot wchodzi na nie, a nie na Twoje produkty. Tag zakładaj tylko wtedy, gdy ma opis i realny ruch.
Po starcie: weryfikacja domeny w GSC, zgłoszenie sitemapy, sprawdzenie raportu „Indeksowanie stron” po 7 i 30 dniach, potem kontrola co kwartał. Jeśli liczba wykluczonych adresów rośnie w kategoriach z produktami, masz problem techniczny, nie treściowy.
| Element | Gdzie to ustawiasz | Co sprawdzić |
|---|---|---|
| Struktura URL | Ustawienia bezpośrednich odnośników / konfiguracja sklepu | Brak /index.php, brak dat i parametrów sesji w adresie |
| Canonical | Szablon, wtyczka SEO lub moduł SEO | Jedna wersja domeny i protokołu dla całej witryny |
| robots.txt | Katalog główny serwera | Brak blokady CSS/JS, wpis Sitemap, brak blokady kategorii |
| sitemap.xml | Wtyczka lub moduł SEO, zgłoszenie w GSC | Tylko adresy indeksowalne, bez tagów i pustych kategorii |
| Dane strukturalne | Organization, Product, BreadcrumbList, FAQPage | Walidacja i brak błędów krytycznych |
| Monitorowanie indeksacji | GSC, raport Indeksowanie stron | Kontrola po 7 i 30 dniach od startu |
Migrację zaczynasz od inwentaryzacji, nie od kopiowania plików. Trzy źródła danych, które musisz zebrać przed jakąkolwiek zmianą DNS:
Z tych trzech list robisz jeden plik: stary adres → nowy adres → typ działania (301/410) → liczba klików w 90 dni. Adresy z ruchem idą na górę kolejki, bo one decydują o przychodzie. Pomocniczo zaciągasz crawling całego serwisu crawlerem pokroju Screaming Frog, żeby wyłapać strony osierocone, których nie ma w sitemapie.
Zasada mapowania 1:1: każdy stary adres ma dokładnie jeden nowy odpowiednik, a przekierowanie ma najwyżej jedno ogniwo. Łańcuch A → B → C gubi część sygnałów i wydłuża ładowanie. Pętla potrafi zablokować stronę całkowicie. Test: curl -I na liście adresów albo crawler z włączonym śledzeniem przekierowań.
Czego nie przenosisz bezmyślnie: opisów produktów skopiowanych od producenta, zdjęć z nazwami typu IMG_2931.jpg (bez altów i z nazwami bez sensu), nieaktualnych wpisów bez ruchu i bez linków. Wszystko to usuwasz, wpisujesz jako 410 i wyrzucasz z sitemapy.
Kolejność: inwentaryzacja → mapa przekierowań → test na kopii → wdrożenie poza godzinami → obserwacja. Pierwsze 30 dni sprawdzasz w GSC raport Strony (404, Strona z przekierowaniem) i porównujesz kliki dzień do dnia. Na 60. dniu patrzysz na pozycje, na 90. – na pełne okno odzyskania ruchu. Temat szerszego przeprojektowania bez spadków opisujemy w materiale o re-brandingu strony internetowej i jego wpływie na SEO.
| Sytuacja | Co ustawić | Dlaczego |
|---|---|---|
| Ta sama treść, nowy adres | 301 | Przenosi ruch i sygnały na nowy URL |
| Treść usunięta na stałe | 410 | Szybciej wypada z indeksu niż 404 |
| Adres z parametrami (?page=2) | 301 na wersję kanoniczną | Bez tego mnożą się duplikaty |
| Adres z linkami zewnętrznymi, treść zniknęła | 301 na najbliższą kategorię | Nie tracisz linków i ruchu |
Utrzymanie to nie „pakiet wsparcia”, tylko zestaw parametrów, które da się wpisać do umowy i rozliczyć. Najważniejsze rozróżnienie: czas reakcji to moment, w którym ktoś zaczyna pracować nad zgłoszeniem. Czas naprawy zależy od przyczyny awarii i nie powinien być gwarantowany w umowie bez widełek.
| Poziom | Przykład zdarzenia | Czas reakcji | Kanał zgłoszenia |
|---|---|---|---|
| Krytyczny (P1) | Strona nie działa, błąd 500, sklep bez dostępu, wygasły SSL | 2–4 h | telefon + e-mail |
| Wysoki (P2) | Płatności lub formularz nie działają części klientów, strona wolna | do 8 h w dni robocze | e-mail + telefon |
| Zwykły (P3) | Zmiana treści, poprawka CSS, nowy banner | do 24 h w dni robocze | e-mail lub panel zgłoszeń |
| Rozwój (P4) | Nowa funkcja, konsultacja, analiza | 2–3 dni robocze |
Punkt przegięcia jest policzalny. Jeśli miesięcznie obsługujesz 50–100 zamówień i stany magazynowe przepisujesz ręcznie, a błędy w fakturach zdarzają się co tydzień – integracja kosztuje mniej niż te godziny. Inne sygnały: zamówienia spływają z kilku kanałów (sklep, marketplace, telefon) do jednego Excela, jedna osoba spędza po kilka godzin dziennie na przepisywaniu danych, klient pyta o status paczki, a nikt nie potrafi odpowiedzieć bez dzwonienia do kuriera.
Kolejność ma znaczenie: najpierw płatności i kurierzy, potem ERP. Powód jest praktyczny – bramka płatności i przewoźnik generują status zamówienia, etykietę i punkt odbioru. ERP ma się do czego podłączyć. Jeśli zaczniesz od ERP, ten narzuci własny workflow i własne statusy, których nie masz skąd zasilić danymi. Drugi etap i tak wymusi przerobienie mapowania statusów, czyli płacisz dwa razy za to samo. Dodatkowo wdrożenie ERP trwa tygodnie lub miesiące, a płatności i kurierów uruchamiasz w kilka dni – i po drodze widzisz realny wolumen zamówień, który potem konfiguruje ERP.
Zakres integracji, który warto rozpisać przed wyceną:
Technicznie: w PrestaShop integrację robi się modułem albo przez zewnętrzny middleware. Dokumentacja deweloperska PrestaShop opisuje moduły, hooki i API, więc przed wyceną da się ustalić, czy wystarczy gotowy moduł, czy potrzebny jest własny kod – zobacz dokumentację dla deweloperów PrestaShop.
Jeśli przy okazji integracji przebudowujesz szablon, wpisz dostępność do wymagań od razu. Poprawianie kontrastu, nawigacji klawiaturą i opisów alternatywnych po wdrożeniu kosztuje więcej niż uwzględnienie ich w projekcie – punkt wyjścia zebraliśmy w artykule o dostępności strony i krokach dla osób niepełnosprawnych.
Zamawianie wyceny bez briefu technicznego, tylko na podstawie liczby podstron.
Jak wykryć: Twoje zapytanie brzmi: ile kosztuje strona 10-podstronowa, i nie ma w nim ani słowa o integracjach, treściach i wielojęzyczności.
Jak naprawić: Wypełnij brief: cel strony, liczba szablonów, integracje z CRM lub ERP, kto dostarcza treści, kto zatwierdza. Dopiero z tego powstaje wycena w godzinach, a nie zgadywanie z liczby podstron.
Brak jednej osoby decyzyjnej po stronie klienta.
Jak wykryć: W wątku mailowym jest pięć osób, każda dopisuje uwagi, ale nikt nie pisze zdania zatwierdzam.
Jak naprawić: Ustal na starcie jedną osobę decyzyjną i jeden kontakt techniczny. Zapisz to w briefie razem z terminem na odpowiedź, np. dwa dni robocze na uwagi.
Treści dostarczane dopiero na końcu projektu.
Jak wykryć: Development się kończy, a tekstów i zdjęć nie ma, więc szablony stoją puste.
Jak naprawić: Rozpisz treści na etapy z terminami już przy briefie. Każdy tydzień zwłoki z materiałami przesuwa start strony o tydzień — to nie kara, tylko arytmetyka kolejki prac.
Mylenie zatwierdzonego projektu graficznego z gotowym wdrożeniem.
Jak wykryć: Po akceptacji makiety klient zakłada, że zostało kilka dni poprawek.
Jak naprawić: Pokazujemy plan etapów z Definition of Done dla każdego z nich. Makieta to jeden z siedmiu etapów, a development to zwykle największa część godzin.
Dokładanie funkcji w trakcie developmentu bez zmiany zakresu.
Jak wykryć: W mailach pojawiają się nowe pomysły, ale nikt nie zapisuje ich jako zmiany zamówienia.
Jak naprawić: Każdą nową funkcję wyceniamy osobno i albo wchodzi do zakresu z nowym terminem, albo ląduje w backlogu na po starcie. Bez tego projekt nie ma końca.
Rezygnacja z opieki po wdrożeniu, żeby zaoszczędzić.
Jak wykryć: Po odbiorze nikt nie robi kopii zapasowych, nie sprawdza alertów i nie mierzy Core Web Vitals.
Jak naprawić: Ustal zakres opieki już przy wycenie: kopie zapasowe, aktualizacje, monitoring dostępności, budżet godzinowy na poprawki. To najtańsze ubezpieczenie wdrożenia.
Wdrożenie strony to proces, nie pojedynczy zakup — im wcześniej znasz etapy, tym mniej niespodzianek w budżecie i kalendarzu. Wycena liczona w godzinach pokazuje, na co idą pieniądze, a Definition of Done daje jasny punkt odbioru. Największym ryzykiem nie jest technologia, tylko brak decyzji i treści po stronie klienta. Zacznij od briefu, resztę zaplanujemy razem.
Sam development to zwykle 30–60 godzin przy prostej stronie firmowej, a rozbudowany serwis to 80–160 godzin. Do tego dochodzi brief, architektura, projekt graficzny, testy i wdrożenie, więc kalendarzowo licz się z kilkoma tygodniami. Największym zmiennym czynnikiem nie jest nasza praca, tylko tempo dostarczania treści i decyzji po stronie klienta.
Nie. Wycena ma zakres i Definition of Done, więc wiemy, co jest w środku, a co jest zmianą zamówienia. Każda nowa funkcja jest wyceniana osobno i wymaga Twojej akceptacji, zanim zaczniemy ją robić. Dzięki temu widzisz, ile kosztuje każdy dodatkowy pomysł, zamiast dowiadywać się o tym na fakturze.
Wtedy, gdy wtyczki trzeba kupić w wersji pro i opłacać co roku, a ich funkcje nachodzą na siebie. Policz koszt licencji w trzyletnim horyzoncie, dodaj czas na konfigurację i aktualizacje, a potem porównaj z jednorazowym kosztem napisania modułu. Często okazuje się, że własny, wąski moduł robi dokładnie to, czego potrzebujesz, bez płacenia za funkcje, których nie używasz.
Brief, architektura i projekt graficzny mogą powstać na podstawie ustaleń, nawet jeśli teksty nie są gotowe. Ale development szablonów bez treści kończy się poprawkami, bo układ dopasowuje się do długości tekstów i liczby zdjęć. Każdy tydzień zwłoki z materiałami przesuwa publikację o tydzień.
Kluczowe pytania to liczba SKU, model sprzedaży i plan rozwoju. WordPress sprawdza się przy stronie firmowej i blogu, WooCommerce przy mniejszych sklepach, a PrestaShop przy większych katalogach i sprzedaży B2B z cenami indywidualnymi. Dokumentację techniczną PrestaShop znajdziesz w dokumentacji dla deweloperów.
Punktem odniesienia są progi Core Web Vitals: LCP poniżej 2,5 s, INP poniżej 200 ms i CLS poniżej 0,1. Sprawdzasz je w PageSpeed Insights, Lighthouse i raportach Search Console, a zakres wskaźników opisuje web.dev. Warto mierzyć to samo przed przebudową i po niej, na tych samych podstronach.
Przekazujemy dostępy, dokumentację i listę kont, a potem wchodzi opieka: kopie zapasowe, aktualizacje, monitoring i budżet na poprawki. Zakres opieki ustalamy przy wycenie, żeby nie było niespodzianek. Praktyczne zasady backupu opisujemy w materiale o kopii zapasowej i Disaster Recovery.
Jeśli chcesz sprawdzić, ile godzin zajmie Twoje wdrożenie, wyślij krótki opis projektu — odpowiemy zakresem i widełkami, bez zobowiązań. Więcej o tym, co wpływa na szybkość strony, znajdziesz w artykule o 10 elementach szybszej strony.