StudioApps · 11 produktów · PL / DACH / EN / ES
Blog / Decyzje

Kiedy oprogramowanie dedykowane ma sens, a kiedy jest przerostem formy

Krótka odpowiedź: dedykowane ma sens, gdy proces jest powtarzalny, kosztowny w obejściu i jest Waszą przewagą. Jeśli któregoś z tych trzech brakuje — gotowe narzędzie będzie tańsze i szybsze. Poniżej cztery progi, po których to rozpoznajemy, i przykłady, kiedy sami odradzaliśmy.

Opublikowano 02.09.2026  ·  9 min czytania  ·  StudioApps

Cztery progi

Próg 1: powtarzalność

Ile razy w tygodniu ktoś w firmie wykonuje tę samą sekwencję ruchów? Jeśli odpowiedź brzmi „raz albo dwa”, budowa się nie zwróci, choćby czynność była irytująca. Jeśli brzmi „codziennie, kilkanaście razy”, warto policzyć.

W jednym z naszych wdrożeń obsługa jednej reklamacji zajmowała około czterech godzin — bo pracownik musiał przejść przez skrzynkę, panel sklepu, historię wysyłek i ustalić, co właściwie się stało. Po zbudowaniu jednego widoku, który zbiera to razem, ta sama sprawa zajmuje 15 minut. Działający system powstał w 27 dni.

Przed
4 godziny
Po
15 minut
Do działającej wersji
27 dni

Próg 2: koszt obejścia

Każda firma, która nie ma własnego systemu, ma zamiast tego obejście: arkusz, którego nikt nie rusza poza jedną osobą; ręczne przepisywanie między dwoma narzędziami; ustalenie, że „Kasia to wie”. Obejście też kosztuje — tylko rachunek nie przychodzi mailem.

Policzcie godziny. Jeśli obejście zjada etat, rozmowa o budowie jest rozmową o pieniądzach, a nie o technologii.

Próg 3: liczba narzędzi do zszycia

Trzy narzędzia, które się nie znają, to jeszcze nie problem. Pięć to już codzienne przeklejanie. Powyżej — nikt w firmie nie ma pełnego obrazu, bo obraz jest rozbity na pięć ekranów.

Przy jednym z systemów akwizycji, który zbudowaliśmy dla siebie, alternatywą było utrzymywanie osobnego narzędzia do wysyłki, osobnego do bazy kontaktów i osobnego do śledzenia, co z tego wyszło. Zamiast tego jest jedna baza i jeden przepływ — i to nie jest wygoda, tylko warunek, żeby ktokolwiek wiedział, na czym stoi.

Próg 4: czyja jest baza klientów

To jest próg, który przesądza najczęściej i najrzadziej pada w rozmowie. Jeśli klient trafia do Was przez cudzą platformę, to jego kontakt należy do tej platformy. Płacicie prowizję za dostęp do własnego klienta.

W systemach rezerwacji, które budujemy, klient rezerwuje i płaci u właściciela obiektu — bez prowizji pośrednika, a kontakt zostaje po stronie właściciela. Jeden z takich systemów obsługuje osiem języków, a strona ładuje się w 0,36 sekundy zamiast poprzednich 1,16.

Kiedy odradzamy

To jest sekcja, której nie znajdziecie w tekstach firm, które takie systemy sprzedają. Piszemy ją, bo źle dobrany projekt kosztuje obie strony — nas reputację, Was pieniądze.

Najczęstszy przypadek, w którym odradzamy: firma chce zastąpić narzędzie, które działa, bo „jest brzydkie”. Brzydota nie jest problemem biznesowym. Prowizja, cztery godziny na sprawę i dane, do których nie macie dostępu — są.

Czego nie kupujecie, kupując system dedykowany

Nie kupujecie tego, że będzie taniej. W pierwszym roku prawie nigdy nie jest — gotowe narzędzie z abonamentem ma niższy próg wejścia i to jest jego uczciwa przewaga.

Kupujecie trzy inne rzeczy: proces dopasowany do tego, jak naprawdę pracujecie, zamiast odwrotnie; dane i kod, które są Wasze; oraz brak rachunku rosnącego z liczbą użytkowników. Czy to jest warte różnicy — zależy od tego, jak wypadły cztery progi powyżej.

Dwa przykłady, w których progi wypadły odwrotnie

Przypadek, w którym budowa miała sens

Sklep internetowy z kilkoma tysiącami pozycji w katalogu. Reklamacje spływały na trzy różne skrzynki, historia wysyłek była w panelu przewoźnika, a informacja o tym, co klient dostał, w panelu sklepu. Pracownik przy każdej sprawie odtwarzał tę układankę od nowa.

Wszystkie cztery progi wypadły na „tak”: kilkanaście spraw dziennie, obejście zjadające realne godziny, cztery narzędzia do zszycia i dane o kliencie rozrzucone tak, że nikt nie miał pełnego obrazu. Efekt po zbudowaniu: cztery godziny na sprawę spadły do piętnastu minut.

Przypadek, w którym odradziliśmy

Firma usługowa chciała własny system do wystawiania ofert, bo w używanym narzędziu „oferty wyglądają brzydko i nie da się wstawić logo tam, gdzie trzeba”. Ofert wychodziło kilka tygodniowo, robiła je jedna osoba, wszystko działo się w jednym narzędziu.

Trzy progi na „nie”, jeden na „tak” — i ten jeden dotyczył wyglądu. Zaproponowaliśmy poprawienie szablonu w narzędziu, które już mieli. Zajęło to dzień. Budowa własnego systemu ofertowania byłaby kilkumiesięcznym projektem rozwiązującym problem estetyczny.

Nie straciliśmy na tym zlecenia — ta sama firma wróciła rok później z czymś, co progi przechodziło. To jest cała ekonomia mówienia „nie” w odpowiednim momencie.

Trzy pytania, które zadajemy w pierwszej rozmowie

  1. Co się stanie, jeśli nic nie zrobicie przez rok? Jeśli odpowiedź brzmi „nic strasznego”, to nie jest projekt na teraz. Jeśli brzmi „nie damy rady obsłużyć wzrostu” — jest.
  2. Kto w firmie będzie tego właścicielem? Nie kto zapłaci, tylko kto codziennie powie, czy to działa dobrze. Bez tej osoby system po roku staje się kolejnym narzędziem, którego nikt nie lubi.
  3. Co już próbowaliście? Odpowiedź „nic” jest ostrzeżeniem. Firmy, które naprawdę mają ten problem, zwykle mają za sobą przynajmniej jedno obejście i potrafią powiedzieć, dlaczego nie wystarczyło.

Te trzy pytania odsiewają więcej niż jakakolwiek analiza techniczna. Odpowiedzi na nie zna właściciel firmy, a nie dostawca oprogramowania — i dlatego to Wy, a nie my, jesteście w stanie rozstrzygnąć tę sprawę.

Co znaczy „przerost formy” w praktyce

Przerost nie polega na tym, że system jest za duży. Polega na tym, że rozwiązuje problem, którego firma jeszcze nie ma — albo ma go w skali, która nie uzasadnia budowy.

Typowe objawy: panel administracyjny z dwudziestoma ekranami, z których używa się trzech. Uprawnienia dla ról, których w firmie nie ma. Raporty, do których nikt nie zagląda. Każda z tych rzeczy kosztowała czas przy budowie i kosztuje przy każdej późniejszej zmianie.

Lekarstwo jest proste i nudne: zbudować to, co jest potrzebne w pierwszym miesiącu, i dołożyć resztę wtedy, gdy okaże się potrzebna. Systemy, które budujemy, wchodzą do użytku po kilku tygodniach właśnie dlatego, że pierwsza wersja robi jedną rzecz porządnie.

Jak to sprawdzić bez rozmowy z kimkolwiek

Weźcie jeden proces, który Was uwiera. Zmierzcie przez tydzień: ile razy się wydarzył, ile minut zajął, ile osób dotknął i w ilu narzędziach się odbywał. Cztery liczby.

Jeśli po tygodniu wychodzi kilkanaście powtórzeń, kilka narzędzi i realne godziny — macie odpowiedź i macie ją policzoną, a nie wyczutą. Jeśli wychodzi „dwa razy, w jednym arkuszu, w pięć minut” — też macie odpowiedź.

Macie podobny problem?

Opiszcie proces, który Was spowalnia. W odpowiedzi dostaniecie ocenę, czy warto budować, orientacyjny koszt i czas. Bez prezentacji handlowej.

Napisz do nas