Gotowy sklep internetowy czy dedykowany projekt: policz koszt trzech lat, zanim podpiszesz umowę

Wybór między gotowym sklepem internetowym a dedykowanym projektem rozstrzyga liczba procesów, których platforma nie obsłuży, a nie wielkość firmy. Przy zerze albo jednym takim procesie dedykowany projekt to droższa wersja tego samego. Policz oba warianty w horyzoncie trzech lat, nie tylko na starcie.

Trzy modele sklepu internetowego: abonament, open source, projekt od zera

Gotowy sklep internetowy, sklep na systemie open source i dedykowany sklep internetowy to trzy modele, które różni przede wszystkim to, kto odpowiada za awarie i aktualizacje.

Gotowy sklep internetowy działa na platformie w abonamencie. Dostawca rozwija oprogramowanie, wdraża aktualizacje bezpieczeństwa i odpowiada za utrzymanie technicznej części systemu. Właściciel sklepu koncentruje się głównie na konfiguracji sprzedaży, wyglądzie, ofercie i integracjach dostępnych w ramach platformy. Przy awarii kontaktuje się z dostawcą usługi, a koszt utrzymania podstawowego środowiska jest zwykle ujęty w opłacie abonamentowej. Zmiana wykonawcy odpowiedzialnego za grafikę, konfigurację czy rozwój sklepu nie oznacza automatycznie zmiany całego oprogramowania.

Sklep na systemie open source działa inaczej. Kod bazowego systemu jest dostępny do użycia i modyfikacji, ale za jego wdrożenie, konfigurację, aktualizacje i bezpieczeństwo odpowiada właściciel sklepu lub zatrudniony wykonawca. Aktualizacje bezpieczeństwa trzeba regularnie instalować, podobnie jak poprawki do rozszerzeń i integracji. Gdy pojawia się awaria, odpowiedzialność zależy od zawartej umowy z agencją, freelancerem albo zespołem technicznym. Zmiana wykonawcy jest możliwa, ale może generować dodatkowy koszt, szczególnie gdy projekt ma słabą dokumentację albo zawiera wiele indywidualnych modyfikacji.

Dedykowany sklep internetowy powstaje jako oprogramowanie pisane pod konkretne wymagania biznesowe. Właściciel otrzymuje większą kontrolę nad logiką systemu, ale jednocześnie musi ustalić, kto po odbiorze będzie rozwijał kod, usuwał błędy i wdrażał aktualizacje bezpieczeństwa. Przy awarii nie ma automatycznie jednego operatora odpowiedzialnego za całą usługę, dlatego znaczenie ma zakres umowy serwisowej. Zmiana wykonawcy może być prosta albo bardzo kosztowna, zależnie od praw do kodu, jakości dokumentacji i dostępu do repozytorium.

Przy wycenach często pojawia się określenie „autorska platforma agencji”. Nie zawsze oznacza ono dedykowany sklep internetowy napisany od zera dla jednego klienta. W praktyce może chodzić o system open source rozbudowany o własną nakładkę, moduły albo zestaw modyfikacji wykonawcy.

Wygląd sklepu nie rozstrzyga wyboru modelu, ponieważ zarówno gotowy sklep internetowy, sklep open source, jak i dedykowany sklep internetowy mogą korzystać z szablonu albo indywidualnego projektu graficznego. Sam model oprogramowania nie przesądza też o widoczności w wyszukiwarce, ponieważ znaczenie ma przede wszystkim sposób wdrożenia i możliwości techniczne konkretnego sklepu.

Jak sprawdzić, czy sklep potrzebuje dedykowanego projektu – test pięciu procesów

Dedykowany projekt ma sens dopiero wtedy, gdy co najmniej dwa procesy krytyczne dla przychodu wypadają poza standard gotowej platformy.

Wielkość firmy nie jest dobrym kryterium wyboru oprogramowania. Duży sklep, który sprzedaje w standardowym modelu, może działać sprawnie na gotowej platformie. Z kolei niewielki biznes z nietypowym konfiguratorem produktu, indywidualnym sposobem wyceny albo złożonym rozliczeniem B2B może potrzebować własnego kodu już od startu. Liczba produktów również nie rozstrzyga wyboru, podobnie jak ambicje wizualne. Najważniejsze pytanie brzmi: ile elementów procesu sprzedażowego rzeczywiście nie mieści się w standardzie platformy.

Test pięciu procesów krok po kroku

Najprostszy test polega na wypisaniu pięciu procesów, które w Twoim sklepie działają inaczej niż u większości konkurentów. Warto sprawdzić przede wszystkim:

1. sposób wyceny produktu, na przykład: widełki cenowe, negocjacje albo indywidualne cenniki,

2. konfigurację produktu, szczególnie gdy wybór wariantów wpływa jednocześnie na cenę i sposób produkcji,

3. rozliczenie z klientem hurtowym, w tym limity kupieckie, płatność odroczoną i rabaty progowe,

4. przepływ zamówienia do produkcji lub podwykonawcy,

5. obsługę zwrotów i reklamacji przy produktach wykonywanych albo konfigurowanych nietypowo.

Każdy proces oceń według jednej z czterech odpowiedzi:

• gotowa platforma obsługuje go w standardzie,

• gotowa platforma obsługuje go po odpowiedniej konfiguracji,

• funkcję można dopisać przez interfejs programistyczny,

• procesu nie da się sensownie obsłużyć bez własnego kodu.

Interfejs programistyczny pozwala połączyć standard platformy z dodatkową funkcją lub zewnętrznym systemem. Dzięki temu brak jednej nietypowej funkcji nie musi od razu oznaczać budowy całego sklepu od zera.

Reguła zero-jeden i warunek utrzymania kodu

Zero albo jeden proces poza zasięgiem gotowej platformy zwykle przemawia za pozostaniem przy rozwiązaniu standardowym. Dedykowany projekt w takim przypadku może okazać się droższą wersją procesu, który da się obsłużyć konfiguracją albo pojedynczym rozszerzeniem.

Dwa lub więcej procesów, które są kluczowe dla przychodu i których nie da się obsłużyć w standardzie platformy ani przez interfejs programistyczny, stanowią mocniejsze uzasadnienie dla własnego kodu.

Drugi warunek dotyczy utrzymania. Przed podpisaniem umowy trzeba wiedzieć, kto po odbiorze będzie odpowiadał za rozwój, poprawki i awarie. Dedykowany projekt bez osoby albo firmy odpowiedzialnej za dalsze utrzymanie kodu tworzy ryzyko niezależnie od tego, jak dobrze został wykonany na starcie.

Do samodzielnej decyzji wystarczy więc prosta matryca: wypisz pięć kluczowych procesów, przypisz każdemu jedną z czterech odpowiedzi i policz, ile z nich faktycznie wymaga własnego kodu.

Ile kosztuje gotowy sklep internetowy, a ile dedykowany projekt?

Gotowy sklep internetowy kosztuje od 119 zł netto miesięcznie bez zobowiązania albo od 29 zł netto miesięcznie przy umowie na 12 miesięcy, a dedykowany projekt od 2500 zł netto do ponad 30 000 zł jednorazowo.

Samo porównanie kosztu startowego może jednak prowadzić do błędnego wniosku. Gotowa platforma opiera się na abonamencie, więc część kosztów rozkłada się w czasie. Dedykowany sklep internetowy zwykle wymaga większego wydatku na początku, ale po odbiorze pojawiają się też koszty utrzymania, rozwoju i opieki technicznej. Po stronie platformy wdrożenie również może być osobną pozycją, dlatego nie wystarczy zestawić ceny abonamentu z wyceną agencji.

Dane rynkowe z grudnia 2025 r. wskazują, że projekt agencyjny o typowym zakresie kosztuje około 2500-7500 zł netto, natomiast projekt z indywidualnymi funkcjami i integracjami może przekroczyć 30 000 zł. Dane rynkowe z czerwca 2025 r. pokazują z kolei, że prosty sklep jednostronicowy może kosztować około 2000-3000 zł netto, bardziej rozbudowany sklep do około 6000 zł netto, a sklep na zamówienie z własnymi wtyczkami kilkanaście tysięcy złotych.

W przypadku gotowej platformy cennik z września 2026 r. przewiduje abonament od 119 zł netto miesięcznie bez zobowiązania albo od 29 zł netto miesięcznie przy umowie na 12 miesięcy. Pakiety wdrożeniowe kosztują od 0 zł do 19 999 zł. Każda wycena indywidualna zależy jednak od zakresu projektu, liczby integracji, potrzebnych modyfikacji i poziomu wsparcia, dlatego ceny mogą zmieniać się w czasie.

Ten sam rachunek w horyzoncie trzech lat

Rzetelne porównanie wymaga policzenia obu modeli w tym samym okresie. Horyzont trzech lat pozwala zestawić opłatę początkową, koszty stałe, rozwój, bezpieczeństwo i wsparcie.

Kwoty utrzymania własnego kodu nie da się wiarygodnie ujednolicić, ponieważ zależy od architektury sklepu, zakresu opieki i warunków umowy z wykonawcą. Podanie jednej orientacyjnej stawki byłoby mniej użyteczne niż wskazanie pozycji, które trzeba wycenić osobno.

Różnica między gotowym sklepem internetowym a dedykowanym projektem może więc wyglądać na niewielką na etapie startu, a znacząco zmienić się po trzech latach. Właśnie dlatego o opłacalności nie powinna decydować wyłącznie pierwsza faktura za wdrożenie.

Koszty dedykowanego sklepu po odbiorze: hosting, aktualizacje, opieka

Dedykowany sklep internetowy generuje po odbiorze dalsze koszty: hosting, aktualizacje bezpieczeństwa, opiekę i każdą zmianę, która na gotowej platformie jest kliknięciem w panelu.

Po zakończeniu wdrożenia właściciel sklepu nadal ponosi koszty związane z utrzymaniem środowiska technicznego. Do najczęstszych pozycji należą aktualizacje bibliotek, poprawki bezpieczeństwa, zmiany wymuszone przepisami, hosting, monitoring dostępności oraz rozwój funkcji. Każda z tych prac wymaga czasu osoby lub firmy, która zna kod i potrafi bezpiecznie wprowadzać zmiany.

Szczególnego znaczenia nabiera odpowiedzialność za awarie. Jeżeli dedykowany sklep internetowy przestanie działać w piątek wieczorem, wcześniej powinno być ustalone, kto odbierze zgłoszenie, w jakim czasie rozpocznie interwencję i czy pomoc poza standardowymi godzinami pracy jest objęta stałą opłatą. Gwarancja na wykonanie nie jest tym samym co umowa o opiekę. Gwarancja dotyczy zazwyczaj błędów wynikających z realizacji projektu, natomiast umowa o opiekę określa bieżące utrzymanie, reakcję na awarie, aktualizacje bezpieczeństwa i dalszy rozwój systemu.

Koszt utrzymania może wzrosnąć także przy zmianie wykonawcy. Jeżeli dotychczasowa firma kończy działalność, zmienia zakres usług albo podnosi stawki, przejęcie projektu przez nowy zespół jest znacznie prostsze, gdy właściciel ma dostęp do repozytorium kodu i kompletnej dokumentacji technicznej. Repozytorium kodu to miejsce, w którym przechowywany jest kod źródłowy wraz z historią zmian. Dokumentacja techniczna opisuje architekturę systemu, integracje, zależności i sposób jego rozwijania. Brak tych elementów może wydłużyć analizę projektu i zwiększyć koszt przejęcia sklepu.

Osiem punktów do ustalenia z wykonawcą przed podpisaniem umowy

Koszt dedykowanego sklepu internetowego zależy nie tylko od ceny jego wykonania, ale również od warunków dalszego utrzymania i możliwości przejęcia projektu. Dlatego jeszcze przed podpisaniem umowy warto ustalić kwestie, które później decydują o kosztach rozwoju, obsługi awarii i ewentualnej zmiany wykonawcy. Poniższe osiem punktów można potraktować jako gotową listę do rozmowy z agencją lub software house’em.

1. Prawa do kodu - ustal, czy kupujesz kod na własność, czy otrzymujesz jedynie licencję na używanie. Brak jasnego zapisu może ograniczyć możliwość modyfikowania lub przekazania projektu innemu wykonawcy.

2. Dostęp do repozytorium od pierwszego dnia projektu - dostęp powinien obowiązywać już podczas prac, a nie dopiero po odbiorze. Brak dostępu zwiększa zależność od jednego wykonawcy.

3. Dokumentacja techniczna jako element odbioru - dokumentacja powinna wchodzić w zakres projektu, a nie być dodatkowo płatnym dodatkiem. Jej brak może zwiększyć koszt przejęcia kodu przez nowy zespół.

4. Warunki opieki po wdrożeniu - ustal zakres, cenę i okres wypowiedzenia umowy o opiekę. Brak takich zapisów utrudnia oszacowanie kosztów utrzymania po odbiorze.

5. Czas reakcji na awarię i wsparcie poza godzinami pracy - określ, kiedy wykonawca rozpocznie interwencję i jak rozliczana jest pomoc wieczorem, w weekend lub w święto. Brak ustaleń może przełożyć się na dłuższy przestój sprzedaży.

6. Aktualizacje bezpieczeństwa i zmiany wymuszone przepisami - zapisz, kto wykonuje takie prace i kto za nie płaci. Bez ustaleń każda aktualizacja może wymagać osobnej wyceny.

7. Koszt zmian po odbiorze - sprawdź, czy dalsze prace są rozliczane według stawki godzinowej, czy według wyceny konkretnego zadania. Brak modelu rozliczeń utrudnia planowanie budżetu na rozwój.

8. Tryb przekazania projektu innemu wykonawcy - ustal, jakie pliki, dostępy, dokumenty i informacje zostaną przekazane przy zmianie firmy. Brak procedury może zwiększyć zarówno koszt, jak i czas potrzebny na przejęcie sklepu.

Dobrze przygotowana umowa powinna więc odpowiadać nie tylko na pytanie, ile kosztuje stworzenie dedykowanego sklepu internetowego, ale również kto będzie go utrzymywał, rozwijał i przejmie odpowiedzialność w razie awarii. Im więcej z tych zasad zostanie zapisanych przed startem projektu, tym łatwiej później kontrolować koszty i zmienić wykonawcę bez konieczności rozpoczynania prac od początku.

Czas wdrożenia: migracja w 2 do 8 tygodni wobec miesięcy budowy od zera

Gotowy sklep internetowy wdraża się w 2 do 8 tygodni, a dedykowany sklep internetowy buduje się miesiącami i termin wydłuża się przy każdej zmianie zakresu.

Przy migracji do gotowej platformy czas wdrożenia zależy przede wszystkim od wielkości katalogu, jakości danych i stopnia skomplikowania struktury sklepu. Sklep z maksymalnie około 1000 pozycji, bez dodatkowych modyfikacji i z prostą strukturą, można przenieść w około dwa tygodnie. Przy rozbudowanych kategoriach, większej liczbie zależności i dodatkowych pracach migracja może potrwać od sześciu do ośmiu tygodni.

Dedykowany sklep internetowy wymaga natomiast zaprojektowania logiki działania, przygotowania kodu, integracji, testów i odbioru. Zakres projektu często rośnie już w trakcie realizacji, ponieważ dopiero podczas prac pojawiają się dodatkowe potrzeby, wyjątki w procesie sprzedażowym albo nowe integracje. Każda taka zmiana może przesunąć termin uruchomienia.

Czas warto traktować jako pozycję kosztową, a nie wyłącznie kwestię wygody. Przy sklepie budowanym od zera koszt czekania ma charakter hipotetyczny, ponieważ firma dopiero planuje sprzedaż. Przy przebudowie działającego sklepu opóźnienie jest łatwiejsze do policzenia, bo można odnieść je do realnej marży generowanej obecnie przez biznes.

Sezonowość sprzedaży dodatkowo zwiększa znaczenie terminu. Przesunięcie uruchomienia sklepu o kwartał może kosztować więcej niż różnica pomiędzy dwiema ofertami wdrożeniowymi, szczególnie gdy opóźnienie obejmuje najważniejszy okres sprzedażowy w roku.

Jak policzyć koszt miesiąca bez sklepu?

Koszt czekania można policzyć na własnych danych, mnożąc miesięczną marżę przez liczbę miesięcy różnicy między wariantami wdrożenia. Do obliczeń należy używać marży, a nie całego obrotu.

Przykładowo, jeżeli sklep generuje 20 000 zł marży miesięcznie, a dedykowany projekt opóźnia start o cztery miesiące względem szybszego wariantu, koszt czekania wynosi 80 000 zł marży. Dla porównania typowa wycena projektu agencyjnego mieści się w przedziale 2500-7500 zł netto.

Koszt czekania nie pojawia się na żadnej fakturze, dlatego łatwo pominąć go w porównaniu, mimo że przy przebudowie działającego sklepu może być jedną z największych pozycji w całym rachunku.

Kiedy dedykowany sklep internetowy się opłaca: cztery sytuacje

Dedykowany sklep internetowy broni się przy konfiguratorze produktu, nietypowych rozliczeniach hurtowych, integracji z produkcją i przy własnym zespole technicznym.

1. Pierwsza sytuacja to rozbudowany konfigurator produktu. Przykładem może być sklep, w którym klient wybiera kilka parametrów towaru, a każda decyzja wpływa nie tylko na cenę, lecz także na sposób wykonania zamówienia. Jeżeli wybór materiału, wymiaru, koloru i dodatkowego wyposażenia musi automatycznie tworzyć specyfikację produkcyjną, standardowy proces sprzedażowy może okazać się niewystarczający. Gdy konfigurator działa jednak jako osobny moduł i tylko przekazuje wynik do koszyka, często wystarczy rozszerzenie gotowej platformy.

2. Drugi przypadek dotyczy sprzedaży B2B z nietypowymi zasadami rozliczeń. Dedykowany sklep internetowy może być uzasadniony, gdy każdy klient hurtowy ma indywidualny cennik, własny limit kupiecki, inne rabaty progowe i odrębne zasady płatności odroczonej. Przykładem jest hurtownia, w której warunki zakupu zależą jednocześnie od grupy kontrahenta, historii współpracy i dostępnego limitu kredytowego. Jeżeli potrzeby ograniczają się do kilku poziomów cenowych i standardowej płatności z terminem, rozszerzenie gotowej platformy może nadal obsłużyć taki model.

3. Trzecia sytuacja pojawia się wtedy, gdy zamówienie ze sklepu musi być bezpośrednio powiązane z procesem produkcyjnym. Integracja z produkcją może obejmować automatyczne przesłanie parametrów zamówienia do systemu ERP, systemu planowania produkcji albo bezpośrednio do maszyn. Przykładem jest firma wykonująca elementy na wymiar, w której zamówienie klienta uruchamia konkretną ścieżkę technologiczną. Jeżeli sklep jedynie przekazuje standardowe dane o zamówieniu do zewnętrznego systemu, gotowa platforma z odpowiednią integracją może być wystarczająca.

4. Czwarty przypadek dotyczy skali biznesu i własnych zasobów technicznych. Własny kod zaczyna mieć więcej ekonomicznego sensu, gdy firma ma stały zespół programistów, regularnie rozwija proces sprzedażowy i może rozłożyć koszt utrzymania oprogramowania na dużą liczbę zamówień. Przykładem jest organizacja, w której sklep jest jednym z kluczowych systemów operacyjnych i wymaga ciągłych zmian powiązanych z innymi narzędziami firmy. Jeżeli firma nie ma własnego zaplecza technicznego, a większość zmian dotyczy pojedynczych funkcji, budowa całego systemu od zera może generować więcej obowiązków niż korzyści.

Granica opłacalności nie przebiega więc przy określonej liczbie produktów ani poziomie obrotu. Dedykowany sklep internetowy zaczyna się bronić wtedy, gdy niestandardowe procesy są częścią samego modelu sprzedaży, a ich obsługa ma bezpośredni wpływ na przychód.

Rozszerzenie gotowej platformy przez API zamiast budowy od zera

Gotową platformę rozszerza się przez interfejs programistyczny, dopisując wyłącznie brakujący proces zamiast budować cały sklep od nowa.

Interfejs programistyczny, czyli API, to sposób komunikacji między platformą sklepową a innymi systemami lub dodatkowymi modułami. Dzięki niemu można zachować standard platformy i jednocześnie rozbudować sklep o funkcję, której gotowe rozwiązanie nie obsługuje w podstawowej wersji. Zamiast finansować budowę całego oprogramowania od początku, firma tworzy tylko brakujący element.

W praktyce przez interfejs programistyczny można rozszerzyć na przykład nietypowy krok w koszyku albo procesie zamówienia, wymianę danych z systemem używanym w firmie czy dodatkową logikę potrzebną do obsługi sprzedaży. Osobny moduł może pełnić również funkcję kalkulatora ceny albo konfiguratora produktu, a następnie przekazywać do standardowego sklepu informacje potrzebne do utworzenia zamówienia.

Platforma IdoSell udostępnia interfejs programistyczny, dlatego część nietypowych procesów można dopisać bez rezygnacji ze standardu platformy.

Takie podejście jest zwykle szybsze i tańsze niż projektowanie całego sklepu od zera, ponieważ nie trzeba ponownie tworzyć elementów, które gotowa platforma już zapewnia. Prace programistyczne koncentrują się na konkretnym procesie, integracji lub module, zamiast obejmować cały mechanizm sprzedaży.

Rozszerzenie przez API ma jednak granice. Jeżeli niestandardowy jest pojedynczy element procesu sprzedażowego, dodatkowy moduł może rozwiązać problem. Jeżeli jednak nietypowe zasady dotyczą większości kluczowych etapów, na przykład sposobu wyceny, konfiguracji produktu, płatności, realizacji i obsługi zamówienia, kolejne nakładki mogą przestać być praktycznym rozwiązaniem. W takim przypadku własny kod może być uzasadniony przez sam model sprzedaży.

Plan wyjścia: w jakiej postaci odzyskasz dane

Przed wyborem gotowej platformy, rozszerzenia przez API albo dedykowanego sklepu warto sprawdzić, w jakiej postaci będzie można odzyskać dane przy późniejszej zmianie rozwiązania. Plan wyjścia powinien obejmować przynajmniej:

• eksport katalogu produktów wraz z podstawowymi danymi potrzebnymi do odtworzenia oferty,

• historię zamówień,

• bazę klientów wraz z informacjami o zgodach marketingowych,

• treści oraz adresy podstron potrzebne do przygotowania przekierowań po migracji.

Znaczenie ma nie tylko możliwość pobrania danych, ale również ich format i kompletność. Plik, którego nie da się łatwo wykorzystać w innym systemie, może oznaczać dodatkowe prace przy migracji.

Odpowiedź na pytanie o sposób odzyskania danych bywa różnicą między sprawną migracją a odtwarzaniem dużej części sklepu od początku, dlatego zasady eksportu warto mieć ustalone na piśmie przed podpisaniem umowy.