Spis treści
1. Szczera odpowiedź: to zależy
Pewnie widziałeś wpisy blogowe twierdzące, że rozszerzenie do Chrome można zbudować za 500 dolarów albo że rozwiązania enterprise kosztują 500 000 dolarów. Obie kwoty krążą w sieci, bo “rozszerzenie do przeglądarki” obejmuje wszystko — od jednoelementowego popupu zmieniającego stronę nowej karty po pełną platformę wstrzykującą złożone interfejsy do aplikacji enterprise SaaS.
Koszt zależy od złożoności, nie od liczby linii kodu. 200-liniowy content script wstrzykiwany do React SPA z izolacją Shadow DOM, logiką ponownego montowania i synchronizacją danych w czasie rzeczywistym jest znacznie trudniejszy (i droższy) niż 2000-liniowe rozszerzenie popup ze stroną ustawień i kilkoma wywołaniami API.
Poniżej dzielimy rozszerzenia na pięć poziomów złożoności z realistycznymi przedziałami cenowymi opartymi na projektach, które faktycznie dostarczyliśmy. To nie są wartości teoretyczne — odzwierciedlają kwoty, jakie nasi klienci zapłacili za produkcyjne rozszerzenia dostępne dziś w Chrome Web Store.
2. Poziomy złożoności rozszerzeń
Każde rozszerzenie, które zbudowaliśmy, mieści się w jednej z tych pięciu kategorii. Przedziały cenowe obejmują projektowanie, development, testowanie, publikację w Chrome Web Store i wstępne wdrożenie. Nie obejmują bieżącej konserwacji (omówionej w sekcji o ukrytych kosztach poniżej).
Poziom 0: MVP / Walidacja
$1 200 – $3 000Fokusowe rozszerzenie MVP zaprojektowane, aby zwalidować Twój pomysł z prawdziwymi użytkownikami przed zaangażowaniem się w pełny projekt. Obejmuje jedną kluczową funkcję, prosty popup lub content script i publikację w Chrome Web Store. Idealne dla founderów testujących product-market fit, zespołów uruchamiających wewnętrzne pilotaże lub agencji eksplorujących usługi rozszerzeń do przeglądarek. Zacznij od małego, ucz się szybko, potem skaluj.
Czas realizacji: 1–2 tygodnie
Poziom 1: Proste rozszerzenie popup
$3 000 – $8 000Interfejs popup ze stroną ustawień/opcji i prostą logiką w tle. Przykład: narzędzie zapisujące preferencje użytkownika, wykonujące kilka wywołań API i wyświetlające wyniki w oknie popup. Bez interakcji z treścią strony internetowej.
Czas realizacji: 2–4 tygodnie
Poziom 2: Rozszerzenie z content scriptem
$8 000 – $20 000Wstrzykuje elementy UI na strony internetowe, odczytuje dane ze strony i wykonuje podstawową manipulację DOM. Przykład: dodawanie przycisków do dashboardu, wyodrębnianie danych z tabel lub wzbogacanie stron produktów o dodatkowe informacje. Działa na stronach statycznych lub renderowanych po stronie serwera.
Czas realizacji: 4–8 tygodni
Poziom 3: Złożone wstrzykiwanie do SPA
$20 000 – $50 000Wstrzykiwanie do aplikacji React, Angular lub Vue typu Single-Page Application. Wymaga izolacji Shadow DOM dla enkapsulacji stylów, synchronizacji danych w czasie rzeczywistym, automatycznego ponownego montowania przy re-renderze aplikacji hosta oraz wielu punktów wstrzykiwania w różnych widokach. To właśnie tutaj żyje większość projektów typu “to się nie da zrobić” — i tu nasza specjalizacja ma największe znaczenie.
Czas realizacji: 8–16 tygodni
Poziom 4: Rozszerzenie platformowe enterprise
$50 000 – $100 000+Pełna platforma dostarczana jako rozszerzenie do przeglądarki. Architektura multi-tenant, przepływy uwierzytelniania i autoryzacji, panel administracyjny, dashboardy analityczne, pipeline CI/CD z automatycznym wdrażaniem do Chrome Web Store oraz wsparcie cross-browser (Chrome, Firefox, Safari). Często obejmuje towarzyszące backend API i panel webowy dla administratorów.
Czas realizacji: 16–32 tygodnie
Uwaga dotycząca tych przedziałów
To są przedziały, nie sztywne ceny. Rozszerzenie poziomu 2 z niezwykle złożonymi integracjami API może kosztować więcej niż prosty projekt poziomu 3. System poziomów to punkt wyjścia do planowania budżetu — rzeczywisty koszt zależy od konkretnych wymagań, które odkryjemy podczas naszego warsztatu zakresowego.
3. Co podnosi koszt
Nie wszystkie funkcjonalności są sobie równe. Niektóre dodają dni do projektu. Inne dodają tygodnie. Oto czynniki, które konsekwentnie podnoszą koszty developmentu rozszerzeń:
Złożoność wstrzykiwania do SPA
To największy czynnik kosztowy. Wstrzyknięcie UI na statyczną stronę HTML jest proste. Wstrzyknięcie do React lub Angular SPA, które ciągle się re-renderuje, używa routingu po stronie klienta i może prowadzić testy A/B zmieniające strukturę DOM — to wymaga fundamentalnie innego podejścia. Nasza wewnętrzna biblioteka react-content-script-injector istnieje właśnie dlatego, że ten problem jest na tyle trudny, by uzasadnić dedykowane narzędzia.
Wsparcie cross-browser
Chrome i Edge współdzielą ten sam silnik (Chromium), więc obsługa obu jest praktycznie darmowa. Firefox korzysta z nieco innego API rozszerzeń (WebExtensions), co wymaga ukierunkowanych dostosowań. Safari wymaga osobnego procesu budowania w Xcode i członkostwa w Apple Developer Program. Każda dodatkowa przeglądarka zwiększa obciążenie testami i utrzymaniem. Dolicz 20–40% więcej za wsparcie Firefoxa i 40–60% więcej, jeśli wymagane jest Safari.
Uwierzytelnianie i autoryzacja
Jeśli rozszerzenie wymaga logowania użytkownika, kontroli dostępu opartej na rolach lub integracji z istniejącym systemem uwierzytelniania (OAuth, SSO, SAML), to znacząco zwiększa złożoność. Rozszerzenia działają w izolowanym środowisku ze ścisłymi politykami bezpieczeństwa, a przepływy auth, które działają bezproblemowo w aplikacji webowej, często trzeba przeprojektować pod kątem kontekstu rozszerzenia.
Integracje API
Każde zewnętrzne API, z którym rozszerzenie musi się komunikować, dodaje czas na development i testowanie. Rate limiting, obsługa błędów, odświeżanie tokenów, transformacja danych — to nie jest efektowne, ale to właśnie tu idzie dużo godzin pracy. Zewnętrzne API wprowadzają też zależności, które mogą się zepsuć lub zmienić bez ostrzeżenia.
Zgodność z Chrome Web Store
Google weryfikuje każde zgłoszenie rozszerzenia. Rozszerzenia wymagające szerokich uprawnień (jak dostęp do wszystkich adresów URL), obsługujące dane użytkowników lub wchodzące w interakcję z wrażliwymi stronami podlegają surowszej kontroli. Budowanie pod kątem zgodności od pierwszego dnia jest tańsze niż przerabianie po odrzuceniu, ale wymaga wcześniejszego zadbania o zakres uprawnień, politykę prywatności i dokumentację przetwarzania danych.
Wymagania dotyczące bieżącego utrzymania
Rozszerzenia wstrzykujące się w strony trzecich są nierozerwalnie powiązane z tymi stronami. Gdy strona hosta zmieni swój interfejs, twoje rozszerzenie może wymagać aktualizacji. Niektóre strony hostów zmieniają się często (co tydzień). Inne są stabilne przez miesiące. Obciążenie utrzymaniem zależy wyłącznie od tego, jak niestabilna jest docelowa strona.
4. Co obniża koszt
Dobra wiadomość: istnieją konkretne sposoby na obniżenie kosztu budowy rozszerzenia do przeglądarki bez poświęcania jakości. Oto co sprawia, że projekty są bardziej przystępne cenowo:
Wykorzystanie sprawdzonych frameworków
Narzędzia takie jak CRXJS, Plasmo i WXT znacząco dojrzały. Obsługują boilerplate developmentu rozszerzeń (generowanie manifestu, HMR, konfiguracja buildu), dzięki czemu developerzy mogą skupić się na logice biznesowej. Używamy CRXJS, ponieważ jesteśmy kontrybutorami projektu i znamy go od podszewki.
Targetowanie tylko przeglądarek opartych na Chrome
Chrome, Edge, Brave, Arc i Opera — wszystkie działają na Chromium. Jeden build obsługuje je wszystkie. Jeśli twoi użytkownicy korzystają z przeglądarek opartych na Chrome (co dotyczy większości narzędzi B2B), pomiń wsparcie Firefoxa i Safari. Zawsze możesz je dodać później, jeśli będzie taka potrzeba.
Jasny zakres na starcie
Najskuteczniejszy sposób na kontrolę kosztów to dokładne zdefiniowanie, co rozszerzenie ma robić, zanim ruszy development. Pełzanie zakresu (scope creep) to powód numer jeden, dla którego projekty przekraczają budżet. 2-godzinny warsztat zakresowy oszczędza tygodnie przeróbek.
Wykorzystanie istniejących bibliotek komponentów
Jeśli nie potrzebujesz w pełni niestandardowego designu, wykorzystanie sprawdzonych bibliotek komponentów UI (Tailwind, shadcn/ui, Radix) znacząco skraca czas developmentu frontendu. Rozszerzenie nadal wygląda profesjonalnie — po prostu nie wymaga, by designer tworzył każdy przycisk i input od zera.
Iteracyjna realizacja (najpierw MVP)
Zacznij od głównego procesu, który oszczędza najwięcej czasu, wdróż go i rozszerzaj stamtąd. Rozszerzenie MVP automatyzujące jedno kluczowe zadanie może być gotowe w 2–4 tygodnie. Zyskujesz natychmiastowy zwrot z inwestycji, podczas gdy my kontynuujemy budowę dodatkowych funkcji w kolejnych iteracjach. Pozwala to też zweryfikować założenia, zanim zaangażujesz cały budżet.
6. Budować samemu, kupić gotowe czy zlecić
Nie każde rozszerzenie musi być budowane od zera. Oto jak myśleć o trzech głównych opcjach:
No-code buildery rozszerzeń
Narzędzia takie jak Extensionify lub szablony rozszerzeń pozwalają tworzyć proste rozszerzenia bez pisania kodu. Dobre do: prostych narzędzi popup, prostych modyfikacji stron, szybkich prototypów. Ograniczone możliwościami buildera — gdy potrzebujesz niestandardowej logiki, wstrzykiwania do SPA lub złożonych przepływów danych, szybko je przerastasz.
Najlepsze dla: przypadków poziomu 1, gdzie szablony buildera dokładnie pasują do twoich potrzeb.
Freelancer
Doświadczony freelancer poradzi sobie z rozszerzeniami poziomu 1 i częścią poziomu 2. Koszt jest zwykle niższy, ale ponosisz ryzyko: jeśli freelancer zniknie, będzie zajęty innym projektem lub nie ma doświadczenia z konkretnymi wyzwaniami twojego projektu (wstrzykiwanie do SPA, Shadow DOM, zgodność z Chrome Web Store), zostajesz z problemem. Brak bieżącego wsparcia, chyba że wynegocjujesz retainer.
Najlepsze dla: projektów o średniej złożoności z jasnym zakresem i bez potrzeb bieżącego utrzymania.
Wyspecjalizowany zespół (jak Optymized)
Dla rozszerzeń poziomu 3 i 4 — złożone wstrzykiwanie do SPA, wdrożenie enterprise, wsparcie cross-browser i bieżące utrzymanie — potrzebujesz zespołu, który już to robił. Dostarczyliśmy ponad 100 aktualizacji rozszerzeń i współtworzymy narzędzia open-source, których inni deweloperzy używają do budowy rozszerzeń. Dostajesz architekturę klasy produkcyjnej od pierwszego dnia, pipeline CI/CD, monitoring błędów, doświadczenie w reverse-engineeringu nieudokumentowanych API, gdy platforma nie oferuje oficjalnych, i zespół, dla którego awaria spowodowana zmianą strony hosta to priorytet — nie kolejny punkt w backlogu.
Najlepsze dla: złożonych, produkcyjnych rozszerzeń, które muszą działać niezawodnie i skalować się.
Nie ma nic złego w rozpoczęciu od narzędzia no-code lub freelancera przy prostym projekcie. Ale jeśli twoje rozszerzenie jest krytyczne dla biznesu — jeśli twój zespół zależy od niego codziennie, jeśli przestoje kosztują realne pieniądze, jeśli musi działać bezbłędnie wewnątrz złożonego SPA — koszt popełnienia błędu jest znacznie wyższy niż koszt zrobienia tego dobrze za pierwszym razem.
7. Jak wyceniamy projekty
Nie rozliczamy się godzinowo. Rozliczenie godzinowe tworzy rozbieżność motywacji — im wolniej idzie praca, tym więcej płaci klient. To zły układ dla wszystkich.
Zamiast tego stosujemy stałe ceny ustalone z góry. Oto jak to działa:
Warsztat zakresowy
Zaczynamy od krótkiego warsztatu (zwykle 1–2 godziny), podczas którego dokładnie mapujemy, co rozszerzenie ma robić. Analizujemy docelową stronę, rozumiemy przepływy pracy, identyfikujemy punkty wstrzykiwania i oceniamy złożoność techniczną. Jest bezpłatny — bez zobowiązań.
Oferta ze stałą ceną
Na podstawie warsztatu dostarczamy szczegółową ofertę ze stałą ceną, jasnym zakresem i harmonogramem realizacji. Wiesz dokładnie, ile płacisz, zanim napiszemy choć jedną linijkę kodu. Żadnych niespodzianek, żadnego zgadywania stawek godzinowych, żadnych “natknęliśmy się na nieoczekiwaną złożoność” przekroczeń.
Iteracyjna realizacja
Dostarczamy w tygodniowych iteracjach z działającymi buildami, które możesz zainstalować i przetestować w swojej przeglądarce. Widzisz postępy co tydzień, nie tylko na końcu. Jeśli priorytety zmienią się w trakcie projektu, dostosowujemy zakres w ramach ustalonego budżetu, zamiast doliczać dodatkowe godziny.
Opcjonalna umowa serwisowa
Po uruchomieniu oferujemy miesięczne umowy serwisowe obejmujące adaptację do zmian na stronie hosta, aktualizacje Chrome API, poprawki błędów i drobne rozszerzenia funkcjonalności. Jest to opcjonalne, ale zdecydowanie zalecamy to dla rozszerzeń wstrzykujących się na strony trzecich.
Rezultat: możesz precyzyjnie zaplanować budżet budowy od pierwszego dnia. Żadnych otwartych kontraktów godzinowych, żadnego “to zależy, ile to potrwa”. Zbudowaliśmy wystarczająco dużo rozszerzeń, by wiedzieć, ile rzeczy naprawdę trwają — i potwierdzamy to stałą ceną za development. Bieżące utrzymanie estymujemy na pierwszy miesiąc, a potem rozliczamy według faktycznego zużycia — z celem zmieszczenia się w budżecie Twojego SaaS-a w ciągu kilku miesięcy od uruchomienia.
Gotowy, by wycenić swój projekt rozszerzenia?
Powiedz nam, co chcesz zbudować. Powiemy ci, do którego poziomu się kwalifikuje, podamy realistyczny przedział budżetowy i umówimy bezpłatny warsztat zakresowy, by ustalić dokładną cenę. Bez zobowiązań, bez pitchu sprzedażowego — tylko konkretna odpowiedź od zespołu, który robił to ponad 100 razy.
