Jak zamówić oprogramowanie dla firmy i nie stracić pieniędzy — poradnik dla niewtajemniczonych

1. Dlaczego 70% projektów IT się nie udaje

Statystyki są bezlitosne. Badania Standish Group od lat pokazują, że mniej niż 30% projektów IT kończy się w terminie, w budżecie i z pełną funkcjonalnością. Reszta — przekracza termin, koszty, albo dostarcza coś, czego nikt nie chce używać.

I nie chodzi tu tylko o wielkie systemy korporacyjne. Dokładnie ten sam wzorzec widzę przy projektach dla małych i średnich firm. Klient zamówił sklep, sklep „jest" — ale nie działa tak, jak miał. Klient zamówił system do rezerwacji — system powstał, ale obsługa go nie używa, bo jest zbyt skomplikowany.

Skąd się bierze ten problem? Z braku komunikacji i braku precyzji na starcie. Klient mówi „chcę sklep", developer rozumie „typowy sklep". Tyle że każdy sklep jest inny, każda branża ma swoje wymagania, każdy proces sprzedaży wygląda inaczej. I ta różnica między tym, co powiedział klient, a tym, co zrozumiał developer — kosztuje.

2. Kiedy potrzebujesz dedykowanego software'u, a kiedy gotowe narzędzie wystarczy

Najdroższe oprogramowanie to nie zawsze to, które kosztuje najwięcej na fakturze. Najdroższe jest to, które kupujesz, a potem nie używasz — albo używasz, ale nie robi tego, co powinno robić dla Twojego biznesu.

Zanim zdecydujesz o dedykowanym rozwiązaniu, zadaj sobie szczere pytanie: czy gotowe narzędzie rozwiąże mój problem w 80%? Jeśli tak — zacznij od gotowego. Możesz zawsze przejść na dedykowane kiedy urośniesz.

Kiedy wystarczy gotowe narzędzie (SaaS / gotowa platforma)

• Twój proces biznesowy jest standardowy i nie odbiega od branżowej normy
• Zaczynasz od zera i nie wiesz jeszcze, jak naprawdę wygląda Twój przepływ klientów
• Budżet jest ograniczony — gotowe rozwiązania są tańsze na start
• Potrzebujesz szybko — gotowe narzędzie wdrożysz w tygodnie, nie miesiące
• Nie masz zasobów do utrzymania własnego systemu

Kiedy potrzebujesz dedykowanego oprogramowania

• Twój proces biznesowy jest niestandardowy i żadne gotowe narzędzie go nie obsługuje
• Integracje z innymi systemami są krytyczne (np. własny magazyn, ERP, specyficzny płatnik)
• Skala działania sprawia, że licencje SaaS stają się droższe niż własny system
• Dane klientów są wrażliwe i nie możesz korzystać z zewnętrznych serwerów
• Masz unikalne IP — algorytm, metodę, proces który jest Twoją przewagą

3. WordPress, SaaS czy aplikacja na miarę — tabela decyzyjna

Kryterium	WordPress / WooCommerce	SaaS (Shopify, BaseLinker)	Dedykowana aplikacja
Koszt startu	Niski–średni (2–20 tys. zł)	Bardzo niski (abonament)	Wysoki (20 tys. zł+)
Czas wdrożenia	2–8 tygodni	Dni–tygodnie	3–12 miesięcy
Elastyczność	Wysoka (wtyczki, modyfikacje)	Ograniczona (zależna od platformy)	Pełna
Utrzymanie	Aktualizacje, hosting	Platforma zarządza	Własny zespół lub umowa
Skalowalność	Dobra do pewnej skali	Dobra, ale rosnące koszty	Pełna kontrola
Dla kogo	Sklepy, strony firmowe, blogi	E-commerce bez IT, szybki start	Unikalne procesy, duże skale

4. Technologie bez żargonu — co to znaczy Laravel, React, WooCommerce

Nie musisz być programistą, żeby rozmawiać z software housem. Ale kilka podstawowych pojęć pomoże Ci nie dać się wciągnąć w przepłacanie za rzeczy, które nie są Ci potrzebne.

Słowniczek technologii dla przedsiębiorcy

• WordPress — system zarządzania treścią. Ponad 40% stron w internecie działa na WordPressie. Dobry dla stron firmowych, blogów, portali, prostych sklepów.
• WooCommerce — wtyczka do WordPressa zmieniająca go w sklep internetowy. Obsługuje płatności, stany magazynowe, zamówienia. Wystarczy dla większości sklepów.
• Laravel — framework PHP do budowania aplikacji webowych. Używany kiedy WooCommerce nie wystarczy — np. przy złożonych systemach rezerwacji, platformach SaaS, panelach dla klientów.
• React — biblioteka JavaScript do budowania interaktywnych interfejsów. Kiedy Twoja aplikacja musi działać bardzo dynamicznie (jak aplikacja mobilna, tyle że w przeglądarce).
• API — sposób komunikacji między systemami. Jeśli chcesz, żeby Twoja strona gadała z systemem płatności, ERP albo zewnętrznym serwisem — potrzebujesz integracji przez API.
• Hosting — serwer, na którym mieszka Twoja strona lub aplikacja. Różni się ceną i wydajnością — ważny wybór, szczególnie dla sklepów z dużym ruchem.

5. Jak napisać brief, który da Ci dobrą wycenę

Brief to dokument opisujący co chcesz zbudować. Im lepszy brief, tym dokładniejsza wycena — i tym mniej niespodzianek w trakcie projektu. Oto co powinien zawierać:

Szablon briefu do software house'u

1. Opis firmy i kontekst — czym się zajmujesz, kto jest Twoim klientem, co sprzedajesz
2. Problem do rozwiązania — dlaczego potrzebujesz oprogramowania? Co teraz nie działa?
3. Opis funkcjonalności — lista konkretnych rzeczy, które system ma robić (bez technicznych szczegółów — Twoja robota to CO, ich robota to JAK)
4. Grupy użytkowników — kto będzie używał systemu? Administrator, klient, pracownik? Co każdy z nich może robić?
5. Integracje — z jakimi innymi systemami ma się łączyć? (płatności, magazyn, poczta, CRM)
6. Budżet i timeline — podaj widełki. To nie osłabi Twojej pozycji negocjacyjnej — pomoże odsiać wykonawców, którzy i tak nie mieszczą się w budżecie
7. Przykłady — strony lub aplikacje, które Ci się podobają i dlaczego

Nie musisz pisać 50-stronicowego dokumentu. Kilka stron konkretnych odpowiedzi na powyższe pytania wystarczy, żeby dostać rzetelną wycenę.

6. Jak czytać wycenę — na co uważać

Masz wycenę. Co teraz? Kilka rzeczy, na które zwróć uwagę:

Dobra wycena powinna zawierać

• Podział na etapy lub moduły — widzisz, za co dokładnie płacisz
• Widełki czasowe przy każdym elemencie (np. „implementacja koszyka: 8–12 godzin")
• Jasne rozróżnienie: co jest w cenie, a co jest out of scope
• Informację o technologiach i dlaczego zostały wybrane
• Warunki płatności — zaliczka, raty, płatność po etapach

Sygnały ostrzegawcze w wycenie

• Jedna kwota bez żadnego rozbicia — nie wiesz, za co płacisz
• Brak informacji o tym, co jest out of scope — wszystko będzie "osobno"
• Zbyt niska cena — zastanów się dlaczego. Często oznacza wycinanie skrótów lub ukryte koszty
• Zbyt krótki timeline przy skomplikowanym projekcie — presja czasowa to przepis na błędy
• Brak możliwości zadania pytań lub modyfikacji zakresu przed podpisaniem

7. Etapy projektu IT od A do Z

Wiedza o tym, jak wygląda dobrze prowadzony projekt, chroni Cię przed złymi wykonawcami. Każdy projekt powinien przechodzić przez te etapy:

Discovery (1–2 tygodnie)

Analiza wymagań, warsztaty z klientem, mapowanie procesów, decyzje technologiczne. Dobry software house nie zaczyna pisać kodu bez dokładnego zrozumienia problemu. Jeśli ktoś chce zacząć „od razu programować" — uciekaj.

Design (1–3 tygodnie)

Makiety (wireframes) i projekt graficzny. Zanim powstanie linijka kodu, powinieneś zobaczyć i zaakceptować, jak aplikacja będzie wyglądać i działać. Zmiany na tym etapie kosztują mało — po napisaniu kodu kosztują dużo.

Development (2–12 tygodni, zależy od zakresu)

Właściwe programowanie. Dobry software house pracuje w sprintach — co 1–2 tygodnie pokazuje postęp. Możesz na bieżąco komentować i zgłaszać zmiany.

Testy (1–2 tygodnie)

Testy funkcjonalne, wydajnościowe, na różnych urządzeniach. Nie wolno tego pomijać. Produkt bez testów to produkt z błędami — tylko jeszcze o tym nie wiesz.

Wdrożenie i szkolenie

Przeniesienie na serwer produkcyjny, konfiguracja, szkolenie użytkowników. Zadbaj o dokumentację — za rok ktoś będzie musiał coś zmienić, i dobrze, żeby wiedział jak.

8. Umowa z software housem — kluczowe punkty

Umowa to Twoja ochrona. Bez dobrej umowy jesteś zdany na dobrą wolę wykonawcy. Oto co musi być w umowie:

• Zakres projektu (scope) — co dokładnie zostanie zrealizowane. Dołącz brief jako załącznik.
• Harmonogram i kamienie milowe — kiedy co ma być gotowe i co się dzieje, kiedy nie jest
• Własność kodu — po zakończeniu projektu kod należy do Ciebie, nie do software house'u
• Gwarancja — minimum 3–6 miesięcy na błędy zgłoszone po wdrożeniu
• Procedura zmian zakresu — jak wyceniane są zmiany poza pierwotnym zakresem
• Dostęp do serwerów i repozytoriów — masz mieć dostęp do swojego kodu w każdej chwili
• Poufność — wykonawca nie może pokazywać Twojego projektu bez zgody
• Warunki rozwiązania umowy — co się dzieje, jeśli coś pójdzie nie tak po drodze

9. Co po wdrożeniu: utrzymanie, hosting, aktualizacje

Wdrożenie to nie koniec — to początek. I wielu klientów jest zaskoczonych, że „gotowy system" wymaga dalszych nakładów. To normalne. Zapytaj o to przed podpisaniem umowy.

Regularny koszt utrzymania obejmuje zazwyczaj

• Hosting — serwer, na którym działa aplikacja. Od kilkudziesięciu do kilku tysięcy złotych miesięcznie zależnie od ruchu i wymagań.
• Aktualizacje oprogramowania — WordPress, wtyczki, framework — wymagają regularnych aktualizacji bezpieczeństwa.
• Monitoring i backup — żebyś wiedział, kiedy coś nie działa, i żebyś mógł wrócić do poprzedniej wersji.
• Umowa SLA — czas reakcji na awarie. Dla sklepu internetowego liczy się każda godzina przestoju.

10. Czerwone flagi przy wyborze wykonawcy

Lista sygnałów, które powinny zapalić lampkę ostrzegawczą:

• Brak portfolio lub brak referencji do sprawdzenia
• Niechęć do spotkania przed podpisaniem umowy
• Obiecują wszystko „na już" bez fazy analizy
• Nie pytają o Twój biznes — tylko o technologię
• Kod jest „ich własnością" — bez Twojego dostępu
• Znikają na kilka dni bez odpowiedzi w trakcie projektu
• Nie mają procesu — każdy projekt to improwizacja
• Płatność tylko z góry, całość — bez etapów

11. Case study: sklep WooCommerce dopasowany pod specyficzne potrzeby klienta

Klient: producent i dystrybutor wyrobów regionalnych. Problem: standardowe sklepy nie obsługiwały specyficznego modelu sprzedaży — różne ceny dla klientów hurtowych i detalicznych, minimalne ilości zamówień na poziomie produktu, integracja z lokalnym systemem fakturowania.

Rozwiązanie

WooCommerce z dedykowaną konfiguracją ról użytkowników, niestandardową logiką cen i integracją API z systemem fakturowym klienta. Projekt realizowany w 3 etapach, z testami na każdym kroku.

Wyniki

• Czas wdrożenia: 9 tygodni (discovery → produkcja)
• Budżet: 22 tys. zł całkowity
• Efekt: obsługa zamówień hurtowych przeniesiona w 80% na sklep (wcześniej ręcznie przez email)
• Czas obsługi jednego zamówienia: z 15 minut do 2 minut

Podsumowanie

Zamawianie oprogramowania nie musi być loteria. Przy odpowiednim przygotowaniu i właściwym wykonawcy to inwestycja, która się zwraca. Zapamiętaj:

• Zacznij od gotowego narzędzia — przejdź na dedykowane kiedy masz powód
• Napisz dobry brief zanim poprosisz o wycenę
• Porównaj wyceny i pytaj o szczegóły, nie tylko o cenę końcową
• Sprawdź umowę pod kątem własności kodu i gwarancji
• Zaplanuj utrzymanie — system nie kończy życia w dniu wdrożenia