Dwa sklepy Magento 2 mogą wyglądać podobnie na pierwszym ekranie, a kosztować zupełnie inaczej. Różnicy zwykle nie widać na makiecie. Siedzi w danych, integracjach, obsłudze błędów, B2B, testach i odpowiedzialności za uruchomienie.
Kwoty netto 50 000 zł i 150 000 zł traktuj jako dwa modelowe zakresy, a nie cennik APK Studio. Chcę na nich pokazać, co może kryć się pod tym samym hasłem: „wdrożenie Magento 2”.
To nie cena samej platformy
Magento Open Source można pobrać bez opłaty licencyjnej, ale darmowy silnik nie oznacza darmowego sklepu. Wdrożenie powstaje z analizy, projektu, konfiguracji, kodu, integracji, danych, testów i uruchomienia. Adobe Commerce ma dodatkowo własny model licencyjny.
Największą częścią budżetu jest więc praca potrzebna do zbudowania konkretnego procesu sprzedaży. Jeśli proces jest standardowy i korzysta z gotowych komponentów, koszt może być relatywnie niski. Jeśli system ma odzwierciedlać indywidualne umowy handlowe, wiele magazynów i nietypowy obieg zamówienia, zakres rośnie bardzo szybko.
Dwa przykładowe zakresy
| Obszar | Wariant bliższy 50 tys. zł | Wariant bliższy 150 tys. zł |
|---|---|---|
| Analiza | Krótki discovery, standardowe procesy | Warsztaty, architektura i wiele scenariuszy wyjątków |
| Frontend | Adaptacja gotowego systemu komponentów | Indywidualny UX/UI i rozbudowany design system |
| Integracje | Jedna dobrze opisana integracja | ERP, PIM, WMS, CRM i procesy asynchroniczne |
| Funkcje | Standardowe B2C | B2B, role, limity, akceptacje i złożone ceny |
| Testy | Testy funkcjonalne i UAT | Automatyzacja, wydajność, bezpieczeństwo i regresja |
| Uruchomienie | Jedna migracja i krótka stabilizacja | Próby migracji, plan wycofania i rozszerzony hypercare |
Wariant za 50 tys. zł może być dobrym wdrożeniem, jeśli naprawdę odpowiada potrzebom firmy. Problem pojawia się dopiero wtedy, gdy próbuje udawać zakres za 150 tys. zł. Wtedy z projektu znikają elementy mniej widoczne: analiza wyjątków, próby migracji, automatyzacja testów i monitoring.
Obszary, które zmieniają budżet
Analiza przedwdrożeniowa
Jeżeli proces jest standardowy i dobrze opisany, analiza może być krótka. Przy wielu spółkach, cennikach, magazynach i rolach kupujących potrzebny jest pełniejszy model procesów. Najdroższe są zwykle decyzje podjęte dopiero w połowie implementacji.
Integracje i dane
Gotowe API nie oznacza gotowej integracji. Trzeba ustalić źródło prawdy, mapowanie, kolejność zdarzeń, ponawianie błędów, monitoring i migrację historii. Do tego dochodzą braki w danych, stare identyfikatory i rekordy, których nikt nie używał od lat.
Frontend i funkcje
Adaptacja gotowych komponentów jest szybsza niż projekt indywidualny. Różnicę tworzą też wyszukiwarka, konfigurator, promocje, konta firmowe, limity kupieckie i niestandardowy checkout. Samo słowo „B2B” potrafi oznaczać zarówno dodatkową rolę klienta, jak i cały system akceptacji zamówień.
Testy i stabilizacja
Budżet rośnie, gdy wykonawca odpowiada za automatyczną regresję, testy obciążeniowe, próby migracji, monitoring i dostępność zespołu po starcie. To nie jest efektowna część projektu, ale realnie ogranicza ryzyko zatrzymania sprzedaży.
Jak porównać oferty?
- Porównaj listę procesów i kryteriów akceptacji, nie liczbę ekranów.
- Sprawdź, kto odpowiada za drugi koniec integracji.
- Oddziel licencje i koszty stałe od jednorazowej implementacji.
- Zapytaj o migrację danych, SEO i plan uruchomienia.
- Ustal, co oznacza błąd, zmiana zakresu i okres gwarancyjny.
Poproś też o założenia i wyłączenia. Jeśli oferta zakłada gotowe makiety, poprawne dane i dostępne API, powinno to być zapisane. Dzięki temu wiesz, co stanie się z budżetem, gdy któreś założenie okaże się nieprawdziwe.
Na czym nie warto oszczędzać?
Gdy trzeba zejść z budżetu, najłatwiej wykreślić analizę, testy i okres stabilizacji, bo nie widać ich na ekranie. To zwykle zły kierunek. Te elementy chronią projekt właśnie wtedy, gdy pojawia się problem.
Lepiej ograniczyć liczbę funkcji pierwszego wydania, rynków albo automatyzacji. Można uruchomić standardowy checkout i rozwinąć go później. Znacznie trudniej naprawić źle zaprojektowany model danych lub integrację, od której zależą wszystkie zamówienia.
Moja zasada: tnij zakres biznesowy, nie podstawy jakości. Mniejszy sklep, który działa stabilnie, jest lepszy niż duży zakres uruchomiony bez testów i planu awaryjnego.
Kiedy etapować wdrożenie?
Jeżeli pełny zakres przekracza budżet, nie usuwaj losowo testów lub analizy. Lepsze jest świadome MVP: najpierw proces generujący większość wartości, potem kolejne rynki, funkcje B2B lub automatyzacje. Architektura powinna od początku uwzględniać te etapy.
Na stronie wdrożenia Magento 2 opisuję sposób pracy od analizy do uruchomienia. Dobrze przygotowany zakres pozwala zdecydować, czy projekt powinien być mały, duży, czy rozłożony w czasie.
Co dzieje się z budżetem po starcie?
Uruchomienie nie zamyka kosztów. Magento 2 wymaga aktualizacji bezpieczeństwa, monitoringu, opieki nad infrastrukturą i kontroli kompatybilności modułów. Dochodzą licencje rozszerzeń, rozwój integracji i zmiany wynikające z nowych procesów biznesowych.
Dobrze napisany i przetestowany sklep jest tańszy w dalszym rozwoju, bo zespół nie boi się każdej aktualizacji. Dlatego patrzę na koszt wdrożenia razem z kosztem kolejnych lat. Tania decyzja architektoniczna potrafi wracać na każdej fakturze za rozwój.
