Na pytanie "jaki sklep internetowy założyć" nie ma jednej odpowiedzi — jest odpowiedź dla konkretnego scenariusza. Najpierw ustalasz, co i komu sprzedajesz, ile masz produktów i wariantów oraz z jakimi systemami sklep musi się łączyć. Dopiero potem wybierasz platformę: SaaS, open source, marketplace albo rozwiązanie custom. Ten artykuł porządkuje decyzje organizacyjne przed startem, żeby nie płacić dwa razy za ten sam błąd. Praktyczne wdrożenia i wycenę znajdziesz w naszym hubie sklepy internetowe.
Kolejność decyzji jest zawsze taka sama: model sprzedaży, potem katalog i integracje, na końcu platforma. Odwrócenie tej kolejności kończy się migracją sklepu po kilku miesiącach.
B2C, B2B czy mixed. B2C to ceny brutto, BLIK, szybki checkout i paczkomat. B2B to ceny netto po zalogowaniu, cenniki indywidualne, limity kredytowe, zamówienia na fakturę z terminem płatności i powtarzalne zamówienia z listy zakupowej. Mixed oznacza jeden katalog i dwie logiki cenowe: da się to obsłużyć grupami klientów, ale każdą promocję trzeba przetestować w obu grupach, bo rabat naliczony od ceny netto i brutto daje inne kwoty. Specyfikę tego scenariusza opisujemy w artykule o sklepie internetowym dla hurtowni.
Model operacyjny.
Progi SKU zmieniają wymagania bardziej niż branża. 20 produktów w 5 rozmiarach i 8 kolorach to 800 kombinacji — katalog wygląda na mały, a zachowuje się jak duży. Przed wyborem platformy odpowiedz też na cztery pytania: czy stany i ceny pochodzą z ERP, czy potrzebujesz dwóch języków i walut, czy ceny są indywidualne per klient, czy sprzedajesz z więcej niż jednego magazynu. Kolejność prac i harmonogram rozpisujemy w materiale o tym, jak założyć sklep internetowy krok po kroku.
| Progi SKU | Co się zmienia w wyborze platformy |
|---|---|
| do 50 | katalog wpiszesz ręcznie; wystarczy SaaS, import plików jest zbędny |
| 50–500 | potrzebny import CSV i sensowne filtry; SaaS zwykle wystarcza, ale sprawdź limit wariantów w planie |
| 500–5000 | open source (PrestaShop, WooCommerce) albo wyższy plan SaaS; indeksy bazy i wydajność zaczynają mieć znaczenie |
| powyżej 5000 | źródłem prawdy musi być ERP lub PIM z eksportem XML; sklep tylko prezentuje i sprzedaje |
Na pytanie, jaki sklep internetowy założyć, odpowiada scenariusz, nie moda. Poniżej cztery ścieżki i to, co realnie za sobą ciągną.
SaaS (Shoper, Shopify, Wix). Start liczony w dniach, panel, hosting i kopie zapasowe po stronie dostawcy, abonament plus opłaty za aplikacje. Ograniczenie pojawia się przy nietypowym checkoutcie, niestandardowym konfiguratorze i integracji z systemem, którego nie ma na liście gotowych wtyczek. Typowo: dni do 2 tygodni wdrożenia.
Open source (WooCommerce, PrestaShop). Brak opłaty licencyjnej, pełna kontrola nad kodem i bazą, własne moduły i dowolny hosting. W zamian bierzesz na siebie aktualizacje, bezpieczeństwo, kopie zapasowe i wydajność. Typowo: 3–8 tygodni przy katalogu do 500 produktów — zakres takiego wdrożenia rozkładamy w tekście o cenie za sklep internetowy z 500 produktami.
Marketplace (Allegro, Amazon, Erli). Ruch przychodzi z platformy, więc start jest szybki, ale płacisz prowizją od sprzedaży, nie budujesz własnej bazy klientów i nie kontrolujesz do końca wyglądu oferty. Najczęściej działa jako uzupełnienie własnego sklepu, nie jako jedyny kanał.
Custom i headless. Sensowne przy nietypowej logice zamówień, dużym ruchu lub wielu kanałach sprzedaży. Koszt to projekt, utrzymanie i zespół, który to utrzyma.
Tabela pokazuje różnice bez marketingowego lania wody. Wiersz SEO warto czytać razem z wytycznymi Google do danych strukturalnych obsługiwanych w wynikach wyszukiwania — SaaS generuje je sam, w open source trzeba to sprawdzić i często dołożyć moduł.
| Kryterium | SaaS | Open source | Marketplace | Custom / headless |
|---|---|---|---|---|
| Koszt startu | abonament i aplikacje; brak kosztu serwera | hosting, wdrożenie, moduły, szablon | opłaty za konto plus prowizje od sprzedaży | budżet projektowy i stałe utrzymanie |
| Czas wdrożenia | dni do 2 tygodni | 3–8 tygodni | 1–3 dni na pierwsze oferty | 2–6 miesięcy |
| Elastyczność | niska, granice panelu | wysoka, kod i baza po Twojej stronie | niska, działasz w szablonie platformy | najwyższa |
| Integracje | gotowe aplikacje z katalogu | własny moduł lub gotowy z rynku | ograniczone do API platformy | dowolne, ale każda kosztuje |
| SEO | podstawy w cenie, mało wpływu na techniczne detale | pełna kontrola nad strukturą i szybkością | pozycjonujesz ofertę w serwisie, nie swoją domenę | pełna kontrola, wymaga pracy |
| Utrzymanie | abonament, rosnący wraz z funkcjami | Twoje lub agencji: aktualizacje, backupy, monitoring | stała obsługa ofert i reklamacji | najwyższe, własny zespół lub umowa SLA |
To najczęstszy dylemat w polskim MŚP, a rozstrzyga go katalog i integracje, nie sympatia do technologii.
PrestaShop. Ma natywne kombinacje wariantów, grupy klientów z cenami specyficznymi, tryb multistore i funkcje B2B bez dokładania wtyczek. W polskim rynku działa dużo gotowych integracji: Subiekt, magazyny, Baselinker, bramki płatności. Kod rozszerzasz modułem, a strukturę produktów i hooki opisuje dokumentacja PrestaShop dla deweloperów. Minus: przy każdej aktualizacji PHP trzeba pilnować zgodności szablonu i modułów.
WooCommerce. Elastyczność WordPressa, bardzo duży ekosystem wtyczek i naturalne łączenie sklepu z blogiem, czyli z content marketingiem. Cena tej elastyczności: każda funkcja to kolejna wtyczka, a każda wtyczka to ryzyko konfliktu, wolniejszego ładowania i osobnego aktualizowania. Przy kilku tysiącach SKU licz się z cache obiektowym i lepszym hostingiem. Orientacyjne koszty rozkładamy w artykule o tym, ile kosztuje sklep internetowy WooCommerce.
Próg decyzyjny. Policz cztery liczby: produkty, warianty, języki i integracje. Do 100 produktów bez wariantów i bez ERP oba systemy są nadmiarowe. Od 500 produktów z wariantami i integracją magazynową PrestaShop daje więcej z pudełka, a WooCommerce wymaga więcej pracy przy wydajności. Przy dużym ruchu porównaj to z progami Core Web Vitals, bo wolny sklep traci konwersję wcześniej niż pozycje.
Kiedy SaaS wygrywa z open source. Gdy nie masz zespołu technicznego ani nikogo, kto zrobi aktualizację bezpieczeństwa, gdy katalog jest prosty, a start potrzebny w dwa tygodnie. Wtedy abonament jest tańszy niż pierwsza poważna awaria. Zobacz też nasze wdrożenia sklepów internetowych i porównaj scenariusze z własnym.
Budżet sklepu dzieli się na dwie części: jednorazowy start i miesięczne utrzymanie. Druga pozycja wraca co miesiąc i to ona najczęściej wywraca kalkulację, gdy została policzona „na oko”.
Koszty startowe — rzędy wielkości, które widzimy w praktyce:
Koszty miesięczne: hosting, abonamenty wtyczek, prowizje operatora płatności (typowo 1–2,5% od transakcji, zależnie od obrotu i negocjacji), opłaty kurierskie (stawki zależą od wolumenu paczek), aktualizacje, backup, wsparcie techniczne, marketing.
Widełki: prosty sklep open source z gotowym szablonem i podstawowymi płatnościami to kilka tysięcy złotych. Wdrożenie z integracją ERP, wariantami produktów i migracją danych — kilkanaście tysięcy i więcej, bo płaci się za godziny, a nie za „lepszą platformę”. Punkt odniesienia dla typowego katalogu znajdziesz w artykule o cenie za sklep internetowy z 500 produktami, a rozbicie budżetu w konkretnym stacku — w tekście o kosztach sklepu WooCommerce.
| Pozycja | Start (jednorazowo) | Utrzymanie (miesięcznie) |
|---|---|---|
| Domena + SSL | 50–120 zł/rok + 0–600 zł/rok | 0 zł (odnowienia roczne) |
| Hosting | 0 zł | 25–80 zł (shared) lub 100–300 zł (VPS) |
| Szablon, moduły, wtyczki | 300–3000 zł | 0–200 zł abonamentów |
| Migracja danych i wdrożenie | 500–3000 zł + godziny pracy | — |
| Płatności i kurierzy | 0 zł (zwykle brak opłaty wdrożeniowej) | 1–2,5% od transakcji + koszt przesyłek |
| Utrzymanie (aktualizacje, backup, wsparcie) | — | 200–1500 zł zależnie od zakresu |
Platformę wybiera się przez integracje, nie przez wygląd szablonu. Zanim porównasz SaaS, open source i marketplace, wypisz systemy, z którymi sklep ma się komunikować w pierwszym miesiącu.
Płatności: BLIK, Przelewy24, PayU, Stripe, portfele Google Pay i Apple Pay oraz płatności odroczone. Sprawdź, czy metoda działa w koszyku i na karcie produktu, czy obsługuje zwroty i autoryzację częściową oraz czy prowizja jest identyczna dla BLIK-a i karty.
Kurierzy: InPost (Paczkomaty), DPD, DHL, Poczta/Ruch. Liczy się nie logo na stronie, a API: generowanie etykiet z panelu, numer śledzenia wracający do zamówienia, aktualizacja statusów, obsługa zwrotów i nadawanie z kilku magazynów.
ERP i księgowość: Subiekt, Comarch Optima, WF-Mag, Fakturownia oraz KSeF. Ustal zakres synchronizacji: stany magazynowe w obie strony, ceny, zamówienia, faktury, uzgodnienia płatności. Bez tego pracownik przepisuje dane ręcznie, a przy 100 zamówieniach miesięcznie robi się z tego etat.
Weryfikacja w 15 minut: zapytaj, czy integracja jest natywna (moduł lub wtyczka dostawcy platformy), czy działa przez pośrednika; kto ją utrzymuje i reaguje na błędy; co się dzieje po aktualizacji platformy; czy jest dokumentacja API i środowisko testowe. Poproś o kontakt do klienta z podobnym ERP — najlepiej z hurtowni, gdzie warianty i stany magazynowe są najbardziej wrażliwe. Więcej o tym w materiale o organizacji wdrożenia sklepu dla hurtowni.
| Obszar | Typowe rozwiązania | Co sprawdzić przed decyzją |
|---|---|---|
| Płatności | BLIK, Przelewy24, PayU, Stripe, Google Pay/Apple Pay, płatności odroczone | Zwroty, autoryzacja częściowa, prowizja per metoda, obsługa reklamacji |
| Kurierzy | InPost Paczkomaty, DPD, DHL, Poczta/Ruch | Generowanie etykiet, numer śledzenia w zamówieniu, zwroty, praca z kilku magazynów |
| ERP i magazyn | Subiekt, Comarch Optima, WF-Mag | Kierunek synchronizacji stanów, częstotliwość, obsługa wariantów i rezerwacji |
| Księgowość i faktury | Fakturownia, KSeF | Kto wystawia fakturę, jak trafia do KSeF, co przy korektach i zwrotach |
| Utrzymanie integracji | moduł natywny albo pośrednik | Kto odpowiada za błędy po aktualizacji platformy i jaki jest czas reakcji |
Hosting testuje się dopiero przy pierwszym ruchu z kampanii. Wtedy okazuje się, czy 1000 wejść nie kładzie koszyka i czy PHP ma dość pamięci na import 2000 produktów.
Wybór serwera: przy kilkudziesięciu produktach i kilku zamówieniach dziennie wystarczy dobry shared z PHP 8.2+ i MySQL/MariaDB. Gdy dochodzą tysiące SKU, warianty, importy CSV albo integracja ERP — przechodzisz na VPS lub serwer dedykowany. Konkretne rzeczy do sprawdzenia w umowie: wersja PHP, limit memory_limit, liczba procesów PHP-FPM, limit zapytań SQL na godzinę, rozmiar bazy, lokalizacja serwera (Polska lub Niemcy = niższe opóźnienia).
Bezpieczeństwo: SSL włączony na całej domenie (z przekierowaniem z http), backup dzienny trzymany poza serwerem, WAF, monitoring dostępności i błędów 500, regularne aktualizacje rdzenia, modułów i wtyczek. Zanim wdrożysz zmiany na produkcji, zrób kopię bazy i plików — rollback po nieudanej aktualizacji bez kopii oznacza kilka godzin przestoju.
Wydajność: cache na serwerze i w aplikacji, CDN dla statyków, kompresja i formaty nowoczesne dla zdjęć (WebP/AVIF), minifikacja CSS i JS. Cel: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1 — progi opisane w dokumentacji Web Vitals. Test rób na telefonie w sieci 4G, nie na biurkowym internecie.
Formalności przed startem: regulamin, polityka prywatności, informacja o cookies z realnym wyborem zgód, obowiązek informacyjny RODO w formularzu zamówienia i newslettera, zapis o administratorze danych i celu przetwarzania. To dokumenty, które muszą być gotowe w dniu uruchomienia, a nie „dopisane później”. Kolejność działań i harmonogram rozkładamy w materiale o tym, jak założyć sklep internetowy krok po kroku.
| Element | Hosting shared | VPS / serwer dedykowany |
|---|---|---|
| Koszt | 300–900 zł/rok | 100–300 zł/mies. (VPS), wyżej przy dedykowanym |
| Zasoby | Współdzielone, sztywne limity pamięci i procesów | Przydziały pod kontrolą, można skalować |
| Kiedy wystarczy | Do kilkuset produktów, kilka zamówień dziennie | Tysiące SKU, warianty, importy CSV, integracja ERP |
| Konfiguracja | Gotowa, ograniczone możliwości zmian | Własne PHP, MySQL/MariaDB, cron, reguły cache |
| Odpowiedzialność za utrzymanie | Po stronie dostawcy | Po stronie wykonawcy lub Twojego zespołu |
Adresy URL ustal przed importem produktów, nie po nim. Wzorzec, który się sprawdza: /kategoria/podkategoria/nazwa-produktu, małe litery, bez polskich znaków, bez ID i bez /index.php. Jeśli wgrywasz 2000 produktów z hurtowni, zmiana struktury po miesiącu oznacza 2000 przekierowań 301 i kilka tygodni spadków w wynikach.
Filtry i sortowanie generują dziesiątki tysięcy adresów typu ?sort=price&page=3&filter=rozmiar-42. Dla nich ustaw canonical na adres kategorii bazowej albo noindex, follow. Wewnętrzna wyszukiwarka /szukaj?q= zawsze dostaje noindex — inaczej Google zaindeksuje setki pustych wyników, a roboty będą chodzić po stronach bez treści.
Dane produktowe: unikalny opis 600–1500 znaków, parametry w tabeli, zdjęcia o krótszym boku min. 1000 px i atrybut alt z nazwą produktu. Skopiowany opis z hurtowni to duplikat, który ma cała branża. W kodzie dodaj Schema.org Product + Offer z polami: name, sku, price, priceCurrency, availability, image. Zakres obsługiwanych typów opisuje dokumentacja danych strukturalnych Google.
Od dnia startu: Search Console zweryfikowana dla domeny, sitemap.xml wskazana w robots.txt, GA4 z celami konwersji (dodanie do koszyka, rozpoczęcie zamówienia, zakup). Raz w tygodniu przeglądaj raport 404 i przekierowuj zgubione adresy na 301.
Szybkość i mobile-first: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1. Mierz na telefonie w sieci 4G, nie na biurkowym monitorze. Formaty WebP, lazy loading poza pierwszym ekranem, limit wtyczek. Jeśli budujesz sklep internetowy na WordPressie, każda dodatkowa wtyczka to kolejne zapytanie do bazy i kolejne ryzyko przy aktualizacji.
| Element | Ustawienie | Dlaczego to ważne |
|---|---|---|
| URL produktu | /kategoria/produkt, bez ID i polskich znaków | Stały adres = brak przekierowań przy zmianach |
| Filtry, sortowanie, paginacja | canonical do kategorii lub noindex, follow | Blokuje duplikaty i infinite crawl |
| Szukajka wewnętrzna | noindex | Puste wyniki nie zbierają ruchu, tylko budżet crawlowania |
| Karty produktu | Product + Offer, unikalny opis, zdjęcia ≥1000 px | Szansa na rich results i lepsze dopasowanie zapytań |
| Monitoring | GSC + sitemap + GA4 + raport 404 | Wykrywasz problem w dniu, w którym powstał |
Najdroższe błędy nie wynikają z wyboru „złej platformy”, tylko z niedomkniętych ustaleń. Cztery rzeczy sprawdzasz przed podpisaniem umowy.
Koszty aktualizacji modułów i zgodności z kolejnymi wersjami rdzenia są opisane w dokumentacji deweloperskiej PrestaShop — warto zajrzeć, jeśli platforma ma pracować 3–5 lat.
| Pułapka | Jak sprawdzić | Sygnał ostrzegawczy |
|---|---|---|
| Ukryte koszty | Policz 3-letnie TCO: abonament + moduły + hosting + aktualizacje | "Szczegóły cennika modułów u dostawcy" |
| Vendor lock-in | Eksport 100 produktów i 100 zamówień z demo do CSV | Eksport tylko w formacie PDF lub brak |
| Brak SLA | Zapytaj o czas reakcji, stawkę godzinową i zakres pakietu | Odpowiedzi tylko ustne, brak w umowie |
| Za duży custom | Podziel funkcje na krytyczne i etap 2 | Lista wymagań dłuższa niż 20 pozycji na start |
| Migracja | Mapa 301, testy na stagingu, obniżony TTL | Start bez listy starych adresów URL |
Kolejność decyzji jest sztywna, bo każda następna zależy od poprzedniej: model sprzedaży → budżet → integracje → platforma → hosting → wdrożenie → testy → start. Jeśli wybierzesz platformę przed listą integracji, wdrożenie zatrzyma się na etapie podłączania magazynu albo ERP. Szerszy opis tego procesu, z kosztami i harmonogramem, znajdziesz w tekście jak założyć sklep internetowy, a gotowe scenariusze wdrożeń w sekcji sklepy internetowe.
Lista poniżej to 14 punktów. Odhaczaj je po kolei i zapisuj decyzje w jednym dokumencie — przy zmianie wykonawcy albo przy audycie kosztów to jedyny wiarygodny punkt odniesienia.
Kryteria gotowości do startu. Sklep jest gotowy, gdy: płatność przeszła test na prawdziwej transakcji i została zwrócona, koszt dostawy policzył się poprawnie dla pięciu różnych koszyków, regulamin i polityka prywatności są opublikowane razem z informacją o 14 dniach na odstąpienie, sitemap jest zgłoszona w Search Console, a backup wykonał się i został raz odtworzony na środowisku testowym. Do tego pisemny kontakt do wsparcia z czasem reakcji. Bez odtworzonego backupu nie ma startu — dane klientów są zbyt drogie, żeby zakładać, że kopia „na pewno działa”.
| Lp. | Punkt | Kryterium zaliczenia |
|---|---|---|
| 1 | Model sprzedaży | B2C, B2B lub mieszany; zapisane zasady cenników i grup klientów |
| 2 | Katalog | Inwentaryzacja: liczba produktów, wariantów, kategorii, atrybutów |
| 3 | Budżet 3-letni | Wdrożenie + abonamenty + moduły + hosting + 10–15% rocznie na utrzymanie |
| 4 | Integracje | Lista systemów (ERP, magazyn, kurierzy, płatności, faktury) i posiadane dostępy do API |
| 5 | Platforma | Wybrana po testach, z potwierdzonym eksportem produktów i zamówień |
| 6 | Hosting | Wymagane wersje PHP i MySQL, SSL, kopie dzienne, staging |
| 7 | Szablon i checkout | Koszyk i płatność w maks. 3 krokach, koszt dostawy widoczny przed płatnością |
| 8 | Dane produktowe | Unikalne opisy, parametry, zdjęcia, uzupełnione stany |
| 9 | SEO techniczne | Adresy URL, canonical, noindex dla filtrów i szukajki, sitemap, Schema Product |
| 10 | Płatności | Minimum dwie metody, test transakcji i zwrotu, potwierdzenie e-mail |
| 11 | Dostawa | Cennik wg wagi lub wartości, integracja z kurierem, etykiety, statusy zamówień |
| 12 | Prawne | Regulamin, polityka prywatności, RODO, 14 dni na odstąpienie, dane firmy |
| 13 | Analityka | GA4 z celami konwersji, Search Console, monitorowanie błędów 404 |
| 14 | Testy i backup | Zamówienie end-to-end na mobile oraz jednokrotne odtworzenie kopii |
Wybór platformy przed ustaleniem modelu sprzedaży. Ktoś porównuje Shoper z WooCommerce, a nie wie jeszcze, czy sprzedaje detalicznie, hurtowo, czy w modelu mieszanym.
Jak wykryć: Zadaj jedno pytanie: wypisz na kartce, kto kupuje (B2C, B2B, mixed) i jak wygląda ścieżka od zamówienia do faktury. Jeśli nie umiesz tego opisać w 10 zdaniach, wybór platformy jest przedwczesny.
Jak naprawić: Zacznij od modelu: kanał sprzedaży, ceny (brutto czy indywidualne netto), logistyka, dokumenty. Dopiero na tym opisie testuj platformy — sprawdzasz, czy obsłużą Twój przypadek bez obejść.
Założenie, że sklep z 30 produktami i sklep z 5000 SKU to ten sam projekt, tylko z większą bazą. To dwa różne wdrożenia z różnym budżetem i innym ryzykiem.
Jak wykryć: Policz nie produkty, a kombinacje: produkty × warianty × języki × magazyny. Jeśli wychodzi kilka tysięcy kombinacji, planowanie "prostego sklepu" jest błędem.
Jak naprawić: Ustal przedział: do 50 produktów, 50–500, 500–5000, powyżej 5000 SKU. Dla każdego progu sprawdź limity platformy (liczba SKU, wariantów, języków) i sposób importu danych.
Pominięcie integracji z ERP i księgowością na etapie wyboru platformy. Potem okazuje się, że stany magazynowe trzeba przepisywać ręcznie, a faktury wystawiać w dwóch systemach.
Jak wykryć: Wypisz, gdzie dziś trzymasz stany i dokumenty: Subiekt, Comarch Optima, WF-Mag, Fakturownia, pliki Excel. Zapytaj, czy integracja jest natywna, czy przez pośrednika.
Jak naprawić: Sprawdź, kto utrzymuje integrację i co się dzieje po aktualizacji platformy. Zapytaj wprost o kierunek synchronizacji: stany, ceny, zamówienia, faktury, KSeF.
Hosting dobrany po cenie, bez sprawdzenia wymagań technicznych platformy i przewidywanego ruchu. Sklep działa na testach, a przy pierwszej kampanii przewraca się.
Jak wykryć: Sprawdź wersję PHP (docelowo 8.2 lub nowsza), wersję MySQL/MariaDB, limity pamięci, dostęp do cron i logów. Zmierz czas odpowiedzi na środowisku produkcyjnym, nie lokalnym.
Jak naprawić: Zaplanuj osobne środowisko testowe i produkcyjne. Dla sklepu z wariantami i integracjami zwykle potrzebny jest VPS lub serwer dedykowany, a nie najtańszy hosting współdzielony.
Brak właściciela sklepu po wdrożeniu: nikt nie aktualizuje modułów, nikt nie robi backupu, nikt nie testuje zamówień po zmianach.
Jak wykryć: Zapytaj: kto wykona aktualizację w przyszłym miesiącu i jak sprawdzi, że koszyk nadal działa? Jeśli odpowiedź brzmi "jakoś to będzie", nie masz procesu.
Jak naprawić: Ustal osobę odpowiedzialną, harmonogram aktualizacji, kopie zapasowe z testem odtworzenia i listę testów po każdej zmianie (zamówienie, płatność, etykieta, faktura).
Budżet policzony tylko na start. W kosztach brakuje prowizji płatności, abonamentów modułów, wsparcia, backupu i marketingu.
Jak wykryć: Rozpisz koszty na dwie kolumny: jednorazowe i miesięczne. Jeśli druga kolumna jest pusta, plan jest niepełny.
Jak naprawić: Dodaj do arkusza koszty miesięczne i roczne oraz założenie, ile zamówień musi wpłynąć, żeby sklep się spinał. Zestawienie pozycji budżetowych znajdziesz też w artykule jak założyć sklep internetowy: organizacja, koszty, harmonogram.
Kolejność jest stała: model sprzedaży, potem katalog i integracje, na końcu platforma. SaaS wygrywa przy prostym katalogu i braku zespołu technicznego, open source przy nietypowych procesach i kontroli nad kodem. Bez policzenia wariantów, języków i integracji każda platforma wydaje się dobra — do pierwszego problemu. Sprawdź checklistę przed podpisaniem umowy, nie po starcie.
Od opisu modelu sprzedaży, nie od porównywania platform. Zapisz, kto kupuje, co sprzedajesz, ile masz SKU i wariantów oraz z jakich systemów korzystasz dziś (magazyn, księgowość). Dopiero ten opis pozwala odrzucić rozwiązania, które nie obsłużą Twojego przypadku. Wybór platformy jest ostatnim krokiem, nie pierwszym.
Przy prostym katalogu i braku zespołu technicznego SaaS zwykle wygrywa: szybciej startuje i nie wymaga utrzymania serwera. Open source ma sens, gdy potrzebujesz nietypowej logiki, rozbudowanych integracji albo sklepu połączonego z contentem. Decyzję podejmuj po sprawdzeniu limitów planu, a nie po liczbie produktów w izolacji.
PrestaShop ma natywne funkcje sklepowe: warianty, ceny B2B, reguły cenowe i integracje z polskimi systemami. WooCommerce wygrywa tam, gdzie sklep jest częścią serwisu treściowego i potrzebujesz ekosystemu wtyczek WordPressa. Próg decyzyjny to liczba wariantów, języków, integracji ERP i przewidywany ruch — przy rosnącej liczbie kombinacji różnice stają się wyraźne. Dokumentację techniczną PrestaShop znajdziesz w PrestaShop Developer Documentation.
Prosty sklep open source z gotowym szablonem to wydatek rzędu kilku tysięcy złotych. Wdrożenie z integracjami ERP, wieloma językami i niestandardową logiką to zwykle kilkanaście tysięcy złotych i więcej — wszystko zależy od liczby godzin. Do tego dochodzą koszty miesięczne: hosting, moduły, wsparcie, prowizje płatności i kurierów. Konkretne pozycje rozpisujemy w artykule ile kosztuje sklep internetowy WooCommerce.
Marketplace daje szybki dostęp do ruchu i płatności, ale nie buduje Twojej bazy klientów ani marki — działasz na cudzych zasadach. Częstym rozwiązaniem jest start na marketplace i równoległe uruchomienie własnego sklepu jako kanału docelowego. Trzeba to jednak zaplanować pod kątem jednego źródła stanów i jednego procesu zamówień.
Zapytaj, czy integracja jest natywna, kto ją utrzymuje i co się dzieje po aktualizacji platformy. Poproś o test na Twoich danych: zmiana stanu, zmiana ceny, nowe zamówienie, faktura. Jeśli odpowiedź brzmi "to się jakoś zsynchronizuje", to nie jest integracja, tylko ryzyko.
Przy kilkudziesięciu produktach, bez wariantów i przy małym ruchu często wystarczy. Gdy pojawiają się warianty, integracje, kilka języków i kampanie reklamowe, hosting współdzielony staje się wąskim gardłem. Warto wtedy zaplanować VPS lub serwer dedykowany razem ze środowiskiem testowym. Zasady pisania treści pod realne potrzeby użytkownika opisuje też dokumentacja Google Search Central.
Jeśli chcesz przeliczyć swój scenariusz na konkretny budżet i harmonogram, napisz do nas. Powiemy wprost, czy wystarczy SaaS, czy potrzebujesz open source z integracjami — a jeśli warto, pokażemy zakres wdrożenia w oparciu o nasze realizacje sklepów internetowych.