Tworzymy witryny i aplikacje, które pracują na Twój biznes, bez kompromisów i ograniczeń. To system dopasowuje się do Ciebie!
Działamy w całej Polsce, z połączeniami do Niemiec, Czech, Holandii, Łotwy i Hiszpanii.
Agenci AI dają nam tempo, jakiego nie da żaden etat. Nie pracujemy jednak sami: współpracujemy z agencjami designu i developmentu, a do wybranych projektów dołączają u nas osoby, które znają daną branżę albo technologię. Kod i wszystko, co trafia do klienta, sprawdzamy według instrukcji z naszego kompendium wiedzy.
Nasz najbardziej rozpoznawalny klient – producent, który od 25 lat wyposaża kluby fitness w Europie. Katalog ~400 produktów, realizacje i ścieżki klubów, studiów i dystrybutorów oraz największego wydarzenia fitness w Europie Środkowej, EU4YA.
To tylko nasze ostatnie wdrożenie.
Zobacz wybrane realizacjeKażda branża ma swoje reguły gry: od rozmiarówek w modzie po palety w ogrodzie. Nie uczymy się na Twoim projekcie: te schematy już przerobiliśmy.
Co możemy dla Ciebie zrobić?
Dziewiętnaście otwartych paczek npm, które łączą Medusę z marketplace'ami, ERP-ami i płatnościami, każda z trybem demo i instalacją w trzech krokach. Kliknij znak na orbicie, żeby zobaczyć, co robi.
Wyróżnione w katalogu integracji Medusy InPost, OLX, Fakturownia, Subiekt nexo i Biała lista VATBaza naszych opinii rośnie z każdym oddanym projektem. Wystawiają je klienci na Clutchu, niezależnej platformie z ocenami firm IT.
Każde wdrożenie zostawia ślad: standardy, playbooki, decyzje i przetestowane moduły trafiają do naszego vaulta. Jest w nim Medusa i headless commerce, integracje z Subiektem, Allegro, Base i KSeF, cenniki B2B, SEO i AEO oraz praca z agentami AI, którzy dostają tę wiedzę na starcie, więc żaden projekt nie zaczyna się od zera.
W sklepach headless backend Medusy wystawia API, a sklep to osobna aplikacja, najczęściej w Next.js. Jeden backend może obsłużyć hurt i detal na kilku rynkach z osobnymi walutami, jak w Crème Bar, a front w Next.js działa m.in. w Oponykola. Przy prostym sklepie z jednym kanałem mówimy wprost, że to przerost formy.
Medusa to nasza główna platforma sklepów i hurtowni: grupy klientów z cennikami, osobne kanały sprzedaży i własne moduły bez ruszania rdzenia. Piszemy do niej wtyczki: pięć z nich zespół Medusy wyróżnił w swoim katalogu, a większość przeklikasz w naszym demo. Na Medusie działają m.in. Oponykola i Crème Bar.
Payload wybieramy, gdy redakcja potrzebuje wygodnego panelu, a treść ma zostać we własnej bazie obok reszty systemu. Tak jest w aplikacji dla Wekert, gdzie blog i panel na Next.js czytają treść z PostgreSQL.
Motywy Shopify budujemy pod markę zamiast kupować gotowce, z własnymi blokami, np. dane techniczne z metapól czy „Kup teraz” prosto do kasy. Shopify bywa też zapleczem sprzedaży za frontem w Webflow, jak w Astriva. Gdy sklep dochodzi do granic platformy, przenosimy go dalej, jak Oponykola na Medusę.
Storesynk przenosi produkty z Shopify do CMS Webflow i dokłada warianty, koszyk, kody rabatowe i konto klienta, bez osadzania gotowych widżetów. Koda Plus jest w katalogu Storesynk Experts jako jedyna firma z Polski. Wdrożyliśmy go w Astriva, w czterech wersjach językowych.
Strony w Webflow budujemy na uporządkowanym systemie klas, z kolekcjami CMS, które redakcja edytuje bez programisty, i wersjami językowymi przez Localization. Kolor lokalu na mapie kondygnacji może brać się wprost ze statusu w CMS. Tak zrobiliśmy m.in. WJ Investment, JW, Astriva i Solski Communications. Mamy certyfikaty Webflow CMS i Layouts.
Na WooCommerce nie budujemy nowych sklepów, przenosimy z niego na Medusę lub Shopify: inwentaryzacja adresów, danych i zapomnianych integracji, przekierowania 301 dla każdego adresu, produkty, klienci i historia zamówień, a po przełączeniu kontrola indeksacji.
Cenniki w hurtowniach na Medusie opieramy na wbudowanych price listach przypisanych do grup klientów, z progami ilościowymi i cenami negocjowanymi. W demo KODA SUPPLY działają B2B Standard i Premium oraz umowa ramowa, a negocjacje cen to nasza osobna wtyczka.
W hurtowniach na Medusie zalogowana firma widzi ceny netto ze swojego cennika, a klient detaliczny ceny brutto. Tak działa demo KODA SUPPLY: katalog netto, VAT 23% doliczany w koszyku, i jedna metoda zaokrąglania od koszyka po fakturę.
Feedy hurtowni mapujemy na kategorie sklepu, dopasowujemy produkty po EAN lub SKU i liczymy ceny regułami marży. Przed nocnym importem porównujemy rozmiar pliku i liczbę pozycji z poprzednim, żeby ucięty plik nie wyzerował połowy oferty.
Saldo i nierozliczone faktury zostają w ERP, a sklep na Medusie pobiera je przez integrację i pilnuje limitu: po przekroczeniu blokuje koszyk, kieruje zamówienie do akceptacji opiekuna albo proponuje przedpłatę. Kredyt kupiecki mamy też jako wtyczkę do Medusy.
Migrację zaczynamy od inwentaryzacji danych, integracji i adresów z ruchem. Każdy URL dostaje przekierowanie 301, nowy sklep budujemy równolegle ze starym, a dane najpierw migrujemy próbnie i sprawdzamy na liczbach. Tak przenieśliśmy Oponykola z Shopify na Medusę, a blog Solski Communications z WordPressa do Webflow.
Przypomnienia o porzuconym koszyku pokazują klientowi jego własne pozycje i wychodzą najwyżej raz na koszyk, tylko gdy koszyk leży od 24 do 72 godzin. Tak działa to we wtyczce e-maili w naszym demo na Medusie, a w audycie UX szukamy miejsc, w których klienci porzucają zakupy.
W hurtowniach dokładamy szybkie zamawianie nad koszykiem: lista SKU wklejona z arkusza, plik, powtórzenie poprzedniego zamówienia albo zapisany koszyk na cykliczne dostawy. Pozycje wycenia cennik danego klienta, co widać w demo KODA SUPPLY.
Rejestracja po NIP to standard naszych hurtowni: dane adresowe zaciągają się same, status sprawdzamy na białej liście VAT, a firmy z UE w VIES. Konto czeka na akceptację opiekuna. Działa to w demo KODA SUPPLY, a Biała lista VAT to nasza wtyczka wyróżniona przez Medusę.
Allegro łączymy ze sklepem po API albo przez BaseLinker, zależnie od tego, czy gotowy konektor udźwignie reguły cen i stanów. Parametry na kartach produktów podpowiadamy z kategorii Allegro, a stan ofert odczytujemy cyklicznie. Mamy też własną wtyczkę Allegro do Medusy. Tak sprzedaje m.in. Oponykola.
BaseLinker prowadzi magazyn i sprzedaż na marketplace’ach, a sklep się z nim synchronizuje zamiast liczyć stany osobno. Nasz moduł w Medusie kolejkuje operacje, pilnuje limitów API i zapisuje każdą wymianę w dzienniku. Tak działa Oponykola, a w Abrams BaseLinker spina katalog z centralnym magazynem.
Optimę łączymy ze sklepami i hurtowniami tak, żeby poziomy cen, rabaty i limity kontrahentów działały w sklepie jeden do jednego, a numery dokumentów wracały do konta klienta. Mapę danych układamy pod ograniczenia Optimy w cennikach indywidualnych i kartotekach.
Ceny mieszkań trafiają do rejestru dane.gov.pl codziennie i bez ręcznego wgrywania: zasób wskazuje stały adres na domenie dewelopera, a portal sam pobiera z niego dzienne pliki CSV. Wymaga tego ustawa o jawności cen. Tak działają serwisy WJ Investment i Firmy Inwestycyjnej JW.
Fakturownia to u nas warstwa księgowa sklepu: dane zamówienia trafiają do niej z NIP-em nabywcy, a dokument powstaje przy zmianie statusu, bez przepisywania. Nasza wtyczka Fakturowni do Medusy, wyróżniona przez Medusę, wystawia jedną fakturę na zamówienie i pokazuje status KSeF. Pracuje m.in. w Crème Bar.
InPost robimy na API ShipX, bez wtyczek-kombajnów: Geowidget w checkoucie, przesyłka, etykieta w PDF lub ZPL i statusy. Tak działa nasza wtyczka InPost do Medusy, wyróżniona przez Medusę, a w sklepie demo paczkomat wybiera się w zamówieniu.
Numer KSeF wraca do zamówienia: w naszej integracji Subiekta nexo mostek odsyła go do sklepu razem z fakturą, a wtyczka Fakturowni pokazuje status KSeF w panelu Medusy. Projektując łańcuch, uwzględniamy korekty, tryb offline i osobny tor B2B i B2C.
OLX podpinamy w tym samym katalogu BaseLinkera co Allegro, więc ogłoszenie, oferta i sklep korzystają z jednego stanu, bez osobnej synchronizacji pod każdy serwis. Ma to znaczenie przy towarze w pojedynczych sztukach, jak opony i felgi w Oponykola. Mamy też wtyczkę OLX do Medusy, wyróżnioną przez Medusę.
Przelewy24 podpinamy jako dostawcę płatności w Medusie, z BLIK-iem i przelewami: zamówienie zakłada backend po powiadomieniu z bramki, a strona powrotu czeka na potwierdzenie i w razie potrzeby sama sprawdza status. Tak płacą polscy klienci Crème Bar, obok Stripe.
Resend wysyła wiadomości z formularza koda.plus: powiadomienie do zespołu i potwierdzenie do nadawcy, przez REST API z funkcji na Cloudflare. Na nim działa też nasza wtyczka e-maili do Medusy, która w demo pokazuje szablony zamówień, wysyłki i porzuconych koszyków.
Sellasist zostawiamy jako miejsce, w którym zespół obsługuje zamówienia i wysyłki. Agent AI nie wykonuje tam żadnych operacji: sprawy wymagające działania, jak zwrot czy reklamacja, przekazuje ludziom. Tak to działa w Abrams.
Stripe podpinamy przez moduł płatności Medusy z Payment Element, a webhook domyka zamówienie, gdy klient nie wróci z banku. Nasza wtyczka Stripe pokazuje w panelu Medusy opłaty, spory i wypłaty, tylko do odczytu. W Crème Bar Stripe obsługuje płatności na wszystkich rynkach, także w euro.
Subiekta nexo łączymy z Medusą naszym mostkiem na Sferze: zamówienia trafiają do Subiekta jako ZK, a WZ, faktury i numery KSeF wracają do sklepu. Wtyczka, wyróżniona przez Medusę, ma w demo kolejkę dokumentów. Z Subiektem nexo pracuje m.in. sklep Crème Bar.
Na Astro stoi koda.plus, hostowana na Cloudflare: statyczny HTML, lokalne fonty, animacje w CSS i GSAP, a JavaScript tylko w komponentach, które go potrzebują. Tak samo budujemy strony wizerunkowe klientów, gdy liczą się SEO i Core Web Vitals.
Projekty w Figmie robimy od razu pod wdrożenie 1:1: komponenty, stany ekranów i tokeny o tych samych nazwach w Figmie i w kodzie, a pliki oddajemy klientowi bez blokad. Tak powstała koda.plus, a przy SpaceForm układ sekcji ustaliliśmy w Figmie przed wdrożeniem, bo stronę czyta i inwestor, i inżynier.
GSAP odsłania sekcje koda.plus przy przewijaniu i prowadzi wejście treści w hero. W WJ Investment dzieli nagłówki na słowa i obraca je kolejno, a w Solski Communications linia przy nagłówku sekcji rośnie jedną interakcją na całą witrynę.
Lenis stosujemy w witrynach z rozbudowaną warstwą wizualną, gdzie płynne przewijanie wspiera odbiór treści, i tylko jeśli nie utrudnia czytania. Działa m.in. w witrynie Webflow producenta ochrony balistycznej Astriva, z katalogiem płyt i kamizelek oraz sekcjami laboratorium.
Next.js wybieramy, gdy strona staje się aplikacją: konta, panel z danymi, integracje. Tryb renderowania ustawiamy osobno dla każdej trasy, bo wszystko dynamicznie to najdroższy wariant. Tak działa m.in. front Oponykola z własnym indeksem katalogu i panel Wekert, a witryna AMARACH TIM jest w całości generowana z góry.
React stosujemy tam, gdzie interfejs ma stan i logikę: koszyk ze stanami na bieżąco, kilka ścieżek płatności, edytory i planery w panelach. Na stronach w Astro, jak koda.plus, wstawiamy go tylko punktowo. Działa m.in. w sklepie Crème Bar, panelu Wekert i Koda Flow, naszym własnym produkcie.
Tailwinda używamy w projektach na React i Next.js z wieloma powtarzalnymi komponentami: kolory i fonty marki definiujemy raz w motywie, więc każda karta trzyma ten sam wygląd. Tak powstała witryna AMARACH TIM. Strona koda.plus ma za to własne style, bez frameworka CSS.
Na Tauri i React działa Koda Flow, nasz produkt: przezroczysta nakładka na Windows, zawsze na wierzchu i przepuszczająca kliknięcia, która ogranicza mdłości przy pracy w podróży. W warstwie Rust działa serwer WebSocket odbierający ruch z telefonu.
three.js napędza trójwymiarowy plus na koda.plus, w hero strony głównej, na podstronach oferty i na stronie O nas. Ładujemy go leniwie po wczytaniu strony, a przy ograniczeniu ruchu w systemie scena w ogóle się nie ładuje.
Algolię dokładamy do sklepów headless, gdy wbudowane wyszukiwanie przestaje wystarczać: osobny indeks na każdy język, tolerancja literówek i aktualizacja indeksu zaraz po zmianie produktu w Medusie. Zapytania idą przez backend, który wybiera indeks według języka strony. Tak działa katalog Crème Bar w trzech językach.
Na Cloudflare działa koda.plus: Astro z adapterem Cloudflare i formularz kontaktowy jako funkcja serwerowa z Turnstile. Stamtąd serwujemy też sklep demo na Medusie, a w Astriva Webflow publikuje witrynę przez sieć Cloudflare jako gotowy HTML z cache.
Nowe sklepy i hurtownie na Medusie stawiamy na Medusa Cloud: zwykle plan Launch, przy ciężkich integracjach z ERP plan Scale z osobnym workerem. Środowiska podglądu służą klientowi do akceptacji zmian, a starsze sklepy z Railway przenosimy bez przepisywania aplikacji.
PostgreSQL to baza pod backend każdego sklepu na Medusie, który wdrażamy, a w Oponykola, Wekert i Abrams stoi na Railway obok aplikacji. Dane zostają w standardowej bazie, więc zmiana hostingu nie wymaga zmiany platformy.
Railway wybieramy, gdy projekt potrzebuje procesu działającego bez przerwy, a nie tylko statycznego frontu: backend z bazą, zadania według harmonogramu, webhooki o każdej porze, PDF-y w headless Chromium. Stoją na nim m.in. backend i front Oponykola, hub agenta AI Abrams i aplikacja Wekert.
Supabase łączymy z Webflow, gdy witryna potrzebuje własnej bazy obok CMS-a. Trzyma to, czego CMS nie umie, np. historię cen każdego lokalu z datami zmian, powiązaną z wpisem w CMS, i z tego codziennie powstaje zbiór do dane.gov.pl. Tak działają serwisy WJ Investment i Firmy Inwestycyjnej JW.
Vercel to obok Cloudflare jedno z dwóch miejsc, gdzie hostujemy fronty w Next.js: prerenderowana strona idzie z cache na brzegu sieci, bez własnego serwera do utrzymania. Klient ma pełny kod i dostępy, więc może zostać albo się przenieść. Tak działa witryna AMARACH TIM.
Zaczynamy od robots.txt: boty zbierające dane do trenowania modeli rozdzielamy od agentów wyszukujących, takich jak OAI-SearchBot czy PerplexityBot. Odpowiedź stawiamy zaraz pod nagłówkiem w formie pytania, a obecność marki w odpowiedziach AI sprawdzamy cyklicznie na pytaniach klientów i w logach serwera.
Kampanii nie prowadzimy, robimy ich techniczną stronę. W panelu Wekert wyniki z Google Ads API (tylko odczyt) stoją obok zapytań ze strony, a reguły zamieniają metryki w krótkie zalecenia, np. przy kampanii, która wydaje budżet bez konwersji.
Search Console podpinamy przy każdym wdrożeniu razem z GA4 i Tag Managerem. Jej raporty są punktem wyjścia audytu SEO, a po migracji sklepu przez pierwsze tygodnie śledzimy w niej indeksowanie, błędy 404 i przekierowania.
Po każdym wdrożeniu koda.plus nasz skrypt zbiera adresy z sitemapy i zgłasza je do IndexNow. Sitemapę pobiera z pominięciem cache Cloudflare, bo tuż po wdrożeniu potrafi wrócić stara, a adresy wycofanych stron z 301 podajemy mu wprost.
Na koda.plus utrzymujemy własny llms.txt: usługi z linkami do oferty, technologie, najczęstsze pytania, dane firmy i krótkie streszczenie po angielsku. Traktujemy go jako dodatek, a nie zamiennik pracy nad treścią i danymi strukturalnymi.
Na koda.plus wystawiamy graf Organization i WebSite oraz BlogPosting we wpisach, a nasz skrypt audytu zgłasza podstrony bez JSON-LD. W sklepach pilnujemy, żeby znacznik Product zgadzał się z ceną i stanem z feedu, a przy migracjach porównujemy dane strukturalne starego i nowego sklepu.
Własną stronę sprawdzamy skryptem, który przechodzi każdy adres z sitemapy i weryfikuje tytuły, opisy, canonical, hreflang i JSON-LD. U klientów zaczynamy od logów serwera i Search Console, a w sklepach ograniczamy adresy z filtrów, które marnują budżet indeksowania.
Blog koda.plus prowadzimy na klastrach tematycznych: frazy zbieramy z podpowiedzi Google własnym skryptem, a wpisy opieramy na tym, co zrobiliśmy przy wdrożeniach. AI pomaga w researchu i szkicach, ale przykłady i redakcja są nasze.
Agent AI przygotowuje odpowiedź na podstawie katalogu, cenników i historii zamówień, a trudniejsze sprawy przekazuje ludziom. U siebie pracujemy z kilkoma agentami naraz: każdy startuje z wiedzą z vaulta, a wszystko, co oddają, sprawdzamy w code review. W sklepie Abrams (RTV, AGD, ogród) agent obsługuje sklep i Allegro.
Agenci AI od bezpieczeństwa przeglądają kod i infrastrukturę na każdym etapie, a zmiany akceptuje nasz zespół. Formularz koda.plus chroni honeypot i Turnstile, a w agencie AI Abrams model dostaje tylko dane potrzebne w danej sprawie i nie wykonuje operacji na zamówieniach.
Czat AI odpowiada na podstawie zasad sklepu i danych zamówień, a gdy sprawa wymaga działania, przekazuje ją zespołowi z informacją, z którego kanału przyszła. Zasady dostawy i zwrotów opisujemy raz dla wszystkich kanałów. Wdrożyliśmy go w sklepie Abrams, gdzie rozmawia z klientami w sklepie i na Allegro.
Na Claude API budujemy agentów w pętli narzędzi: model sam decyduje, czy przeszukać bazę wiedzy, sprawdzić zamówienie, czy przekazać sprawę człowiekowi, i odpowiada z danych firmy, a nie z pamięci. Z Claude pracujemy też przy własnym kodzie. W projektach klientów model dobieramy pod ich wymagania.
Kilku agentów AI pracuje z nami równolegle, a wszystko, co oddają, sprawdzamy według instrukcji z vaulta. Bez akceptacji naszego zespołu w code review zmiana nie trafia na produkcję. Możemy też wejść w proces review zespołu klienta albo zrobić audyt kodu.
Przez MCP dajemy agentom AI dostęp do narzędzi i danych potrzebnych w konkretnym zadaniu, np. przy analizie logiki biznesowej firmy. W sklepach na Medusie możemy wystawić przez serwer MCP wybrane dane i operacje, tak żeby asystent działał tylko w ustalonych uprawnieniach.
KODA Vault, który właśnie oglądasz, to nasza baza wiedzy w Obsidianie: standardy, playbooki i decyzje z wdrożeń, które agenci AI dostają na starcie projektu. Dla Wekert zbudowaliśmy notatki na wzór Obsidiana, w których checkbox staje się zadaniem w planerze.
Projekt dzielimy na wycinki, np. cenniki, integrację z ERP, testy i SEO, a każdy dostaje osobnego agenta AI pracującego równolegle. Wszyscy startują z tego samego vaulta, a składanie całości, architektura i akceptacja w code review zostają po naszej stronie.
Każde wdrożenie dopisuje do vaulta standardy, decyzje i sprawdzone moduły, a agenci AI dostają je na starcie kolejnego projektu. Tak lekcje z jednego sklepu, np. o limitach API BaseLinkera czy o integracji Subiekta, trafiają od razu do następnego.
Zmiany w działających sklepach testujemy na środowisku odwzorowującym produkcję. Testy to osobny wycinek dla agenta AI, a wynik sprawdzamy w code review. Większe funkcje włączamy najpierw dla wybranych kontrahentów i zawsze mamy ścieżkę wycofania.
Koda Plus to zespół, który buduje kompletne systemy sprzedaży w internecie: hurtownie B2B i sklepy e-commerce (m.in. na Medusa.js, Shopify i Webflow), strony internetowe i aplikacje webowe, projektowanie graficzne, automatyzacje procesów oraz optymalizację SEO i AEO. Wszystko w jednych rękach: od pierwszego projektu po skalowanie.
Mamy siedzibę we Wrocławiu, a zespół pracuje też z Trójmiasta. Realizujemy projekty w pełni zdalnie dla klientów z całej Polski: komunikacja, spotkania i przekazywanie plików odbywają się online.
Wycena zależy od zakresu: inaczej wygląda landing page, a inaczej rozbudowany sklep B2B z integracjami. Nie narzucamy technologii ani pakietów: po krótkiej, bezpłatnej rozmowie przygotowujemy wycenę dopasowaną do celu i budżetu.
Sklepy stawiamy najczęściej na Medusa.js (headless, open-source) oraz Shopify, a strony na Astro, Next.js i Webflow. Dobieramy stack pod konkretny projekt, tak aby dawał pełną własność kodu i danych oraz szybkie ładowanie.
Tak. Przekazujemy cały kod źródłowy i wszystkie dostępy, bo należą do Ciebie. Nie uzależniamy klientów od siebie; możesz rozwijać projekt u nas albo z dowolnym innym zespołem.
Typowe wdrożenie zajmuje od 4 do 8 tygodni, zależnie od złożoności. Prostsze strony powstają szybciej, a rozbudowane sklepy z integracjami ERP, płatności i logistyki wymagają więcej czasu. Terminy ustalamy na starcie i komunikujemy postępy na każdym etapie.
Medusa.js to headless open source: zero opłat licencyjnych i prowizji platformy, pełna własność kodu oraz dowolna logika B2B (cenniki per klient, rejestracja po NIP, quick-order). Shopify wygrywa szybkim startem w prostym B2C, ale ogranicza customizację i dolicza stałe opłaty, a WooCommerce z czasem wymaga dziesiątek wtyczek. Dlatego hurtownie i nietypowe procesy budujemy najczęściej na Medusie.
ERP i księgowość (Subiekt GT, Comarch Optima, Fakturownia), logistyka (InPost ShipX, kurierzy), marketplace'y (Allegro, bezpośrednio po API lub przez Base), płatności (Przelewy24, Stripe) oraz KSeF. Piszemy też integracje dedykowane pod system, który już masz.
Tak. Krajowy System e-Faktur jest obowiązkowy od lutego 2026 dla największych firm, od kwietnia 2026 dla pozostałych podatników VAT, a od stycznia 2027 dla najmniejszych. Integrujemy wystawianie i odbiór e-faktur bezpośrednio z procesem zamówień sklepu lub hurtowni.
Nad projektem pracuje równolegle kilku agentów AI karmionych naszą bazą wiedzy, ale nic nie trafia na produkcję bez kontroli: agent weryfikuje agenta, a finalne code review robimy my. Dedykowani agenci bezpieczeństwa prześwietlają kod i infrastrukturę na każdym etapie, a architektura zostaje w naszych rękach.
Zaczynamy od bezpłatnej rozmowy online, na której poznajemy zakres, integracje i termin, jakiego potrzebujesz. Potem dostajesz wycenę rozbitą na etapy razem z harmonogramem. Po akceptacji podpisujemy umowę i ustalamy datę startu. Przez cały projekt Twoim kontaktem jest jeden z założycieli, Remigiusz albo Adrian, bez przekazywania sprawy do account managera. Pracujemy po polsku i po angielsku.
Umowa opisuje zakres, harmonogram, płatności rozliczane etapami oraz przeniesienie na Ciebie autorskich praw majątkowych do kodu wraz z polami eksploatacji. Polskie prawo autorskie wymaga, żeby wymienić je wprost, a samą umowę zawrzeć na piśmie. Etapy układamy tak, żeby było widać, za co płacisz i w jakiej kolejności powstają funkcje. Jeśli zakres zmienia się w trakcie, ustalamy to osobno przed rozpoczęciem prac, a nie po fakcie na fakturze.
Tak. Możemy wejść w konkretny obszar: backend na Medusa.js, integrację z ERP, frontend albo automatyzacje, i pracować w Twoim repozytorium, procesie code review i systemie ticketów. Możemy też zrobić audyt istniejącego kodu i przekazać rekomendacje, bez przepisywania wszystkiego od zera. Podział odpowiedzialności ustalamy na starcie, żeby nie dublować pracy i nie blokować się nawzajem przy wdrożeniach.
Po starcie możesz zostać u nas na utrzymaniu: monitoring, aktualizacje, poprawki i dalszy rozwój. Warunki SLA i czasy reakcji ustalamy indywidualnie, bo inaczej wygląda to przy hurtowni B2B pracującej na integracjach z ERP, a inaczej przy stronie firmowej. Jeśli utrzymanie przejmuje Twój zespół, robimy przekazanie: dokumentację, środowiska i sesję wdrożeniową dla programistów.
Tak, w Medusa.js standardem są grupy klientów z własnymi cennikami, a na wierzchu można nałożyć ceny negocjowane dla konkretnej firmy i progi ilościowe. Cenniki zwykle synchronizujemy z ERP, żeby handlowiec nie utrzymywał ich w dwóch miejscach. Klient po zalogowaniu widzi tylko swoje warunki, a gość widzi ceny katalogowe lub nie widzi ich wcale. To decyzja biznesowa, nie ograniczenie techniczne.
Formularz rejestracji pobiera dane firmy po NIP z rejestru REGON (bezpłatne API GUS), więc klient nie przepisuje nazwy i adresu z faktury. Status VAT sprawdzamy w systemie właściwym dla sytuacji: dla polskich firm w wykazie podatników VAT prowadzonym przez KAS (biała lista, API Ministerstwa Finansów), dla kontrahentów z UE w VIES. To dwa różne narzędzia do dwóch różnych transakcji. Nowe konto trafia do moderacji: dopóki opiekun nie zatwierdzi firmy i nie przypisze grupy cenowej, klient nie widzi cen hurtowych. Odpowiedź z VIES warto zapisać przy koncie razem z numerem potwierdzenia (consultation number), bo ważny numer VAT-UE podany przez nabywcę to warunek zastosowania stawki 0% przy WDT, a nie tylko dobra praktyka.
Tak, konto firmowe ma przypisany limit kredytowy i termin płatności (np. 30 dni), a przy składaniu zamówienia system sprawdza dostępne saldo i przeterminowane faktury. Medusa.js ma wbudowane akceptacje koszyka i limity wydatków pracownika, a limit kupiecki i saldo dokładamy na wierzchu, bo to dane z ERP. Po przekroczeniu limitu koszyk może się zablokować, przejść do akceptacji opiekuna albo zaproponować przedpłatę. Logikę ustalamy pod Wasz proces. Salda i rozliczenia zostają po stronie ERP, więc sklep pyta o nie przez integrację, zamiast trzymać drugą wersję prawdy.
Tak, jedna instalacja Medusa.js obsługuje oba kanały: ten sam katalog i magazyn, a inne ceny, minima logistyczne i sposób prezentacji zależą od tego, czy klient jest zalogowany jako firma czy kupuje detalicznie (służą do tego kanały sprzedaży). Hurtownik dostaje ceny netto, MOQ i opakowania zbiorcze (koszyk zaokrągla do pełnego kartonu), a detalista dostaje ceny brutto i klasyczny koszyk. Quick-order po SKU lub kodach EAN z wklejonej listy albo pliku CSV dobudowujemy nad koszykiem. Alternatywnie robimy dwa frontendy na wspólnym backendzie, jeśli marki mają się różnić wizualnie.
Medusa to open source'owy backend e-commerce w Node.js i TypeScripcie, na licencji MIT, rozwijany przez duńską firmę Medusa (Medusa Commerce ApS z Kopenhagi) razem ze społecznością na GitHubie, z regularnymi wydaniami i komercyjną ofertą chmurową Medusa Cloud. Wersja 2.0 jest stabilna od października 2024 i działa produkcyjnie w sklepach oraz hurtowniach B2B, od małych wdrożeń po duże marki, a modułowa architektura pozwala dopisać własną logikę zamiast obchodzić ograniczenia platformy. Ryzyko „zniknięcia dostawcy" jest tu mniejsze niż w SaaS: kod i dane masz u siebie, a licencja MIT pozwala utrzymywać projekt dalej, nawet gdyby jego kierunek się zmienił. Przy wyborze stacku omawiamy też scenariusz wyjścia i utrzymania długoterminowego.
W klasycznym sklepie (WooCommerce, PrestaShop) backend i warstwa prezentacji są zrośnięte: szybciej wystartujesz, ale każda nietypowa zmiana kończy się nadpisywaniem szablonów i wtyczek. W headless frontend jest osobną aplikacją rozmawiającą z backendem przez API: dowolny wygląd, jeden backend obsługuje sklep, panel B2B i aplikację mobilną, a o wydajność łatwiej, bo frontend serwujesz statycznie z CDN. Ceną jest większa złożoność: dwa wdrożenia, więcej pracy na starcie i osobne utrzymanie obu warstw. Headless ma sens przy nietypowych procesach, integracjach z ERP albo więcej niż jednym kanale sprzedaży; przy prostym sklepie z półki bywa przerostem formy. Wtedy też to powiemy.
Za sam software nie płacisz opłat licencyjnych ani prowizji od obrotu. Koszt to hosting, baza danych i utrzymanie, więc nie rośnie automatycznie z liczbą zamówień, jak bywa w SaaS. Frontend hostujemy na Cloudflare lub Vercel, backend i bazę na serwerze albo w chmurze (VPS, kontener, zarządzany PostgreSQL, do tego Redis i miejsce na pliki). Dochodzą aktualizacje, monitoring i zmiany rozwojowe, a ich zakres ustalamy indywidualnie. Konkretną wycenę hostingu podajemy dopiero przy znanym ruchu i katalogu, bo różnica między małym sklepem a hurtownią z tysiącami SKU jest znacząca.
Da się, o ile migracja jest zaplanowana przed wdrożeniem, a nie po. Podstawa to mapa przekierowań 301 stary URL → nowy dla wszystkich produktów, kategorii i wpisów, zachowanie struktury adresów tam, gdzie to możliwe, przeniesienie tytułów, opisów meta i danych strukturalnych oraz przygotowanie nowej mapy witryny. Po starcie monitorujemy Google Search Console pod kątem błędów 404 i spadków, żeby reagować w pierwszych tygodniach. Krótkie wahania pozycji przy zmianie platformy się zdarzają i nikt nie zagwarantuje tu terminu, ale przy poprawnych przekierowaniach i szybszym frontendzie ruch zwykle wraca w ciągu kilku tygodni.
AEO (Answer Engine Optimization) to przygotowanie treści tak, by modele AI (ChatGPT, Perplexity, Gemini czy AI Overviews i AI Mode w Google) potrafiły je poprawnie zacytować i wskazać źródło. W praktyce oznacza to czytelną strukturę nagłówków, dane strukturalne schema.org (Product, Organization, BreadcrumbList), konkretne odpowiedzi zamiast ogólników i szybki, serwerowo renderowany HTML, który nie wymaga JavaScriptu do pokazania treści. Robimy to razem z klasycznym SEO, bo fundamenty są wspólne, a ruch z asystentów AI szybko rośnie. Według danych Adobe w I kwartale 2026 konwertował lepiej niż ruch spoza AI. Warto też sprawdzić, czy botów wyszukujących (OAI-SearchBot, PerplexityBot) nie blokuje robots.txt albo reguły CDN, bo to one odpowiadają za cytowania, a nie boty trenujące modele.
Pierwsze efekty techniczne, czyli indeksację, poprawę Core Web Vitals (LCP, INP, CLS) i wejścia na frazy z długiego ogona, widać zwykle po kilku tygodniach od startu. Na realny wzrost ruchu i sprzedaży z fraz konkurencyjnych trzeba liczyć kwartały, bo Google potrzebuje czasu, żeby zebrać sygnały o nowej domenie, a treść i linki muszą się odłożyć. Nowa domena startuje wolniej niż migracja sklepu z historią: przy przenosinach z zachowaniem przekierowań 301 pozycje zwykle wracają w kilka tygodni. Nie obiecujemy konkretnych pozycji, bo nikt uczciwie nie może. Zamiast tego ustalamy mierzalne cele w Search Console i analityce.
Skupiamy się na warstwie technicznej i danych, a nie na codziennym prowadzeniu kampanii, bo nie jesteśmy agencją mediową. Robimy to, co decyduje o skuteczności reklam: feed produktowy do Google Merchant Center, poprawne tagowanie zdarzeń, integrację z Allegro i innymi marketplace'ami przez API (synchronizacja ofert, stanów magazynowych i zamówień do jednego panelu) oraz automatyzacje po stronie sklepu. Jeśli masz swojego specjalistę od Ads, dostaje od nas czysty feed i działający tracking; jeśli nie, możemy polecić sprawdzonych partnerów.
Standardowo wdrażamy GA4 z e-commerce'owymi zdarzeniami (view_item, add_to_cart, begin_checkout, purchase), Google Tag Manager i Search Console, a przy większym ruchu tracking server-side, żeby dane nie ginęły przez blokery i ograniczenia przeglądarek. Do tego dochodzi banner zgód z Consent Mode v2. W UE jest wymagany, jeśli korzystasz z reklam i remarketingu Google, a bez niego dane są niepełne. Ponieważ Medusa jest open source i baza zamówień należy do Ciebie, możemy zbudować raport marży i realnej rentowności kanałów, którego nie zrobisz na zamkniętej platformie. Zakres ustalamy na starcie, bo nie każdy sklep potrzebuje od razu pełnego stacku analitycznego.
15 minut rozmowy wystarczy, abyśmy wiedzieli, czy pasujemy do Twojego projektu.
Zaczynamy od Twoich potrzeb, nie od gotowego rozwiązania.
