Oprogramowanie na zamówienie: jak wybrać firmę? 14 pytań

Oprogramowanie na zamówienie: jak wybrać firmę, która je napisze, i nie przekonać się po roku, że kod jest nie do przejęcia, a system rozumie tylko jeden programista? Oferty od kilku wykonawców potrafią mocno różnić się ceną, a wszystkie brzmią podobnie. Różnice wychodzą dopiero w umowie, w dokumentacji i w tym, co dzieje się po wdrożeniu. Poniżej zebraliśmy 14 pytań, które warto zadać każdej firmie programistycznej przed podpisaniem umowy, czerwone flagi w odpowiedziach i porównanie freelancera, małego software house'u i dużej firmy.

Artykuł w skrócie

Najważniejsze pytania dotyczą nie technologii, tylko tego, co zostaje u Ciebie: dokumentacji przed kodem, przeniesienia praw autorskich do kodu, dostępu do repozytorium i możliwości przejęcia systemu przez inny zespół.
Płać za etapy, które możesz odebrać i sprawdzić. Wycena stała ma sens przy dobrze opisanym zakresie, rozliczenie godzinowe przy zakresie, który będzie się zmieniał.
Freelancer, mały software house i duża firma różnią się głównie ciągłością, procesem i minimalnym budżetem. Dobór wykonawcy zależy od tego, jak krytyczny dla firmy będzie system.

Oprogramowanie na zamówienie: jak wybrać firmę do jego stworzenia?

Porównuj wykonawców po tym, jak zabezpieczają Twoją firmę, a nie po prezentacji i stawce. Dobry wykonawca najpierw zadaje dużo pytań, potem opisuje system na piśmie, a dopiero na końcu podaje cenę. Słaby podaje cenę po pierwszym spotkaniu.

Dedykowane oprogramowanie dla firm to inwestycja na lata. System rozliczeń, magazynu czy obiegu zamówień będzie rozwijany długo po wdrożeniu, często przez innych ludzi niż ci, którzy go zaczęli. Dlatego pytania poniżej dotyczą głównie tego, co się stanie, gdy coś pójdzie inaczej, niż zakładano. Jeśli wybierasz wykonawcę strony internetowej, a nie systemu, zajrzyj do osobnego poradnika: jak sprawdzić agencję WWW przed zleceniem projektu.

14 pytań do firmy programistycznej przed podpisaniem umowy

Dokumentacja i zakres

1. Czy przed programowaniem powstanie dokumentacja, którą zatwierdzę? Dokumentacja opisuje procesy, ekrany, role użytkowników, reguły (np. jak liczy się rabat albo dzierżawa) i integracje. To ona jest podstawą wyceny i odbioru. Bez niej spór o to, czy system jest „gotowy”, rozstrzyga pamięć obu stron. Zapytaj też, czy dokumentacja zostaje u Ciebie, nawet jeśli nie podpiszesz umowy na budowę.

2. Ile pytań zadacie przed wyceną i kto z naszej strony będzie potrzebny? Wykonawca, który nie pyta o wyjątki, nie zna ich i wyceni system bez nich. W projekcie dla ABC Szalunki klient dostał 55 pytań w dziesięciu obszarach tego samego dnia, w którym przyszło zapytanie. Zanim powstała pierwsza linia kodu, odtworzyliśmy wzór z arkusza klienta i sprawdziliśmy go rachunkiem na prawdziwym zestawieniu^[1].

3. Jakie będą kryteria odbioru? Kryterium odbioru to zdanie, które da się sprawdzić, np. „zestawienie z systemu zgadza się co do grosza z ręcznym rozliczeniem”. Dobre kryteria wynikają ze scenariuszy w dokumentacji i stają się scenariuszami testów odbiorczych.

Kod, prawa autorskie i dostęp

4. Kiedy i w jakim zakresie przechodzą na nas autorskie prawa majątkowe do kodu? Program komputerowy podlega ochronie jak utwór literacki (art. 74 ust. 1 ustawy o prawie autorskim). Umowa o przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności (art. 53), a obejmuje tylko pola eksploatacji wyraźnie w niej wymienione (art. 41 ust. 2)^[2]. Przy programie komputerowym ustawa wymienia m.in. zwielokrotnianie, tłumaczenie, przystosowywanie i inne zmiany w programie oraz jego rozpowszechnianie (art. 74 ust. 4), więc te uprawnienia powinny znaleźć się w umowie wprost. Moment przejścia praw ustala umowa. Często jest to chwila zapłaty za dany etap. Zapytaj też o łańcuch praw: program napisany przez pracownika w ramach obowiązków należy do pracodawcy, jeśli umowa nie stanowi inaczej (art. 74 ust. 3), ale programista na umowie B2B nie jest pracownikiem. Software house musi więc mieć od niego przeniesione prawa na piśmie, żeby móc je przenieść na Ciebie.

5. Czy dostaniemy kod źródłowy i dostęp do repozytorium od pierwszego dnia? Przeniesienie praw nie oznacza automatycznie przekazania kodu. Jeżeli umowa nie stanowi inaczej, przejście autorskich praw majątkowych nie powoduje przeniesienia na nabywcę własności egzemplarza utworu (art. 52 ust. 2)^[2]. Umowa powinna wprost mówić, że dostajesz kod źródłowy wraz z historią zmian. Najprościej, gdy repozytorium jest założone na koncie Twojej firmy, a wykonawca ma do niego dostęp, a nie odwrotnie.

6. Na czyim koncie będą serwer, domena i usługi zewnętrzne? Serwer, domena, klucze do API, konta w bramce SMS czy u dostawcy poczty powinny należeć do Ciebie. W ABC Szalunki system przenieśliśmy z naszej infrastruktury na serwer wykupiony na konto klienta, z porównaniem liczby rekordów przed i po migracji^[1].

7. Jakie zewnętrzne biblioteki i usługi płatne wejdą do systemu? Komponenty z licencją komercyjną albo usługi rozliczane za użycie (np. e-podpis, modele językowe, mapy) to koszt, który zostaje po wdrożeniu. Lista powinna być w dokumentacji razem z kosztem miesięcznym.

Jakość i gwarancja

8. Jak testujecie system i czy testy zostają w repozytorium? Testy automatyczne sprawdzają przy każdej zmianie, czy coś, co działało, nadal działa. Bez nich każda poprawka niesie ryzyko, że zepsuje inną część systemu. W projekcie ABC Szalunki przy każdej zmianie uruchamia się 3649 testów automatycznych, a po każdym większym wdrożeniu kod przechodzi trzy przeglądy kodu: bezpieczeństwa, poprawności rachunkowej i zgodności z zamówieniem^[1].

9. Czy system zostanie sprawdzony na naszych prawdziwych danych? Testy na przykładach dowodzą, że reguła jest dobrze napisana. Dopiero przeliczenie kopii pełnych danych pokazuje, czy jest dobrze zastosowana. To pytanie szczególnie ważne przy migracji danych ze starego programu.

10. Jaka jest gwarancja i co dokładnie obejmuje? Gwarancja powinna mieć czas trwania, zakres (błędy w działaniu zgodnie z dokumentacją, a nie nowe funkcje) i czas reakcji na zgłoszenie. Na systemy dedykowane i sklepy dajemy 12 miesięcy gwarancji^[3].

Pieniądze i zmiany

11. Wycena stała czy rozliczenie godzinowe (time and material)? Wycena stała to kwota za opisany zakres. Sprawdza się, gdy dokumentacja jest szczegółowa. Time and material to płatność za przepracowane godziny. Sprawdza się, gdy zakres będzie się zmieniał w trakcie. Przy obu modelach pytaj o stawkę godzinową i liczbę godzin, bo dopiero cena podzielona przez stawkę pokazuje, ile pracy wykonawca planuje. U nas to 200 zł netto za godzinę, a model rozliczenia ustalamy w załączniku prac do każdego projektu.

12. Jaki jest harmonogram płatności? Przy większym projekcie płatności powinny być powiązane z etapami, które odbierasz, a ostatnia transza powinna przypadać po odbiorze. U nas przy mniejszych projektach to 100% z góry, przy większych 30/70 albo 30/40/30, zawsze z ostatnią transzą po odbiorze^[3]. Ile realnie kosztuje taki system, pokazujemy w artykule ile kosztuje dedykowane oprogramowanie.

Po wdrożeniu

13. Kto i za ile utrzymuje system po wdrożeniu? Utrzymanie to hosting, kopie zapasowe, aktualizacje bezpieczeństwa i drobne poprawki. W naszych wyliczeniach przyjmujemy na nie zwykle 10-15% wartości projektu rocznie^[4]. Poproś każdego wykonawcę o tę kwotę na piśmie, bo to koszt na lata. Zapytaj, czy kopie zapasowe są sprawdzane odtworzeniem, a nie tylko wykonywane, i czy utrzymanie możesz zawiesić albo przenieść do innego wykonawcy.

14. Co się stanie, gdy programista, który pisał system, odejdzie? To pytanie rozstrzyga o ryzyku całego projektu. Odpowiedź powinna wskazywać konkretne rzeczy: dokumentację techniczną, instrukcję obsługi, testy, opis wdrożenia i repozytorium, z których inny zespół może przejąć system. U nas po gwarancji możesz zostać w ramach utrzymania albo przejąć system samodzielnie, bo masz kod źródłowy i dokumentację.

Jak sprawdzić referencje software house'u?

Poproś o kontakt do klienta z podobnym projektem i porozmawiaj z nim bez obecności wykonawcy. Portfolio pokazuje efekt, rozmowa z klientem pokazuje, jak wyglądała współpraca, gdy coś poszło nie tak.

Zapytaj klienta o trzy rzeczy: czy system powstał w terminie i budżecie (a jeśli nie, to dlaczego), jak wykonawca reaguje na błędy po wdrożeniu i czy dostał kod oraz dokumentację. Sprawdź też, czy opisane w realizacjach liczby są konkretne. Opis typu „usprawniliśmy procesy” niczego nie dowodzi. Przykład opisu, który da się zweryfikować, to nasza realizacja systemu rozliczeń dla ABC Szalunki: dokumentacja z 31 regułami naliczania, 2136 z 2136 dokumentów zgodnych z sumami kontrolnymi starego programu, instrukcja obsługi licząca ponad sto stron i lista tego, co jeszcze jest w realizacji^[1].

Czerwone flagi przy wyborze wykonawcy

Cena po pierwszej rozmowie. Bez analizy procesu wycena jest zgadywaniem, a różnicę zapłacisz później w aneksach.
Brak dokumentacji przed kodem. „Zaczniemy, a szczegóły ustalimy po drodze” oznacza, że kryteria odbioru powstaną dopiero w sporze.
Kod i serwer na koncie wykonawcy, bez zapisu o przekazaniu. W razie konfliktu system zostaje u niego.
Umowa bez przeniesienia praw autorskich albo bez listy pól eksploatacji. Bez zgody uprawnionego ustawa pozwala tylko na zmiany niezbędne do korzystania z programu zgodnie z przeznaczeniem, w tym poprawianie błędów (art. 75 ust. 1)^[2]. Rozwijanie systemu, za który zapłaciłeś, albo zlecenie tego innej firmie może wymagać zgody wykonawcy.
Całość płatna z góry przy dużym projekcie. Przy małym zleceniu przedpłata bywa normalna, przy systemie za kilkadziesiąt tysięcy złotych płatności powinny iść za etapami.
Brak testów automatycznych i „testuje klient”. Każda zmiana po wdrożeniu stanie się loterią.
Obietnica dużego systemu w kilka tygodni. U nas typowy projekt dedykowany to 4-12 tygodni od dokumentacji do wdrożenia, a duże systemy mogą trwać 3-6 miesięcy i wdrażamy je etapami^[3].
Odmowa kontaktu z klientem. Poufność bywa uzasadniona przy szczegółach, ale nie przy samym fakcie, że projekt powstał i działa.

Freelancer, mały software house czy duża firma?

Freelancer jest najtańszy i najszybszy na start, ale całe ryzyko wiedzy o systemie leży w jednej osobie. Mały software house daje proces i ciągłość przy rozsądnej stawce. Duża firma ma zespoły i procedury, ale zwykle zaczyna od wyższych budżetów i dłuższego wejścia w projekt. Stawek rynkowych nie podajemy, bo nie znaleźliśmy publicznego badania, które rzetelnie je porównuje. Poproś każdego wykonawcę o stawkę i szacunek godzin na piśmie i porównuj oferty na tych samych założeniach.

Kryterium	Freelancer	Mały software house	Duża firma
Analiza i dokumentacja	rzadko, zależy od osoby	zwykle w procesie	osobny etap, często płatny osobno
Ciągłość przy odejściu osoby	niska	średnia do wysokiej, zależna od dokumentacji	wysoka
Kontakt z decydentem	bezpośredni	bezpośredni, często z właścicielem	przez kierownika projektu
Kiedy wybrać	mały, odizolowany moduł lub prototyp	system dla firmy produkcyjnej lub handlowej, rozwijany etapami	projekty z dziesiątkami integracji, przetargi, wymagania korporacyjne

Freelancer może być dobrym wyborem przy dobrze opisanym, małym zadaniu. Przy systemie, na którym firma prowadzi rozliczenia czy magazyn, pytania 4, 5 i 14 stają się ważniejsze niż różnica w stawce.

Kiedy napisanie programu na zamówienie nie ma sensu?

Gdy proces jest standardowy, a gotowy program obsługuje go bez obchodzenia. Fakturowanie, kadry czy prosta księgowość rzadko wymagają systemu na zamówienie. Dedykowany system ma sens tam, gdzie gotowiec zmusza zespół do pomocniczych arkuszy, podwójnego wpisywania danych i naginania procesu. Oba podejścia porównujemy w tekście system dedykowany czy gotowy. Uczciwy wykonawca powinien powiedzieć Ci to przed podpisaniem umowy, a nie po.

Jak pracujemy przy oprogramowaniu na zamówienie?

Zaczynamy od rozmowy i analizy, potem piszemy dokumentację (zwykle 5-50 stron), a dopiero po jej zatwierdzeniu programujemy, sprintami, z postępem pokazywanym po każdym sprincie. Każdy projekt ma umowę o współpracy i załącznik prac z zakresem, harmonogramem i modelem rozliczenia, NDA podpisujemy na życzenie, także przed pierwszą rozmową. Po wdrożeniu przekazujemy dokumentację, dostępy i szkolenie, a na system dajemy 12 miesięcy gwarancji^[3]. Zakres systemów, które budujemy, opisujemy na stronie oprogramowanie dedykowane dla firm produkcyjnych i handlowych.

Czytaj też: System MES dla małej firmy produkcyjnej, Automatyzacja procesów w firmie: przykłady.

Źródła

KamikStudio - ABC Szalunki: system rozliczeń wynajmu szalunków (case study), dostęp 25.10.2026.
ISAP - Ustawa z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych, tekst jednolity Dz.U. 2025 poz. 24 (art. 41, 52, 53, 74, 75), dostęp 25.10.2026.
KamikStudio - Rozwiązania dedykowane: proces, gwarancja, płatności, terminy, dostęp 25.10.2026.
KamikStudio - Ile kosztuje dedykowane oprogramowanie, dostęp 25.10.2026.

Najczęściej zadawane pytania

Jak wybrać firmę do stworzenia oprogramowania na zamówienie?

Porównuj wykonawców po tym, co zostaje w Twojej firmie: dokumentacja zatwierdzona przed kodem, przeniesienie autorskich praw majątkowych z listą pól eksploatacji, kod źródłowy i repozytorium, testy automatyczne, gwarancja z określonym zakresem i płatności powiązane z etapami. Porozmawiaj też z klientem wykonawcy, który miał podobny projekt.

Czy kod oprogramowania na zamówienie należy do zamawiającego?

Tylko jeśli tak stanowi umowa. Umowa o przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności (art. 53 ustawy o prawie autorskim) i obejmuje tylko pola eksploatacji wyraźnie w niej wymienione (art. 41 ust. 2). Przekazanie kodu źródłowego trzeba zapisać osobno, bo jeżeli umowa nie stanowi inaczej, przejście praw nie przenosi własności egzemplarza utworu (art. 52 ust. 2).

Co wybrać: wycenę stałą czy rozliczenie godzinowe?

Wycena stała sprawdza się, gdy zakres jest szczegółowo opisany w dokumentacji i nie będzie się zmieniał. Rozliczenie godzinowe (time and material) jest lepsze, gdy zakres będzie ewoluował albo projekt rozwija się etapami. W obu modelach warto znać stawkę godzinową i szacowaną liczbę godzin, bo dopiero razem pokazują, ile pracy wykonawca planuje.

Freelancer czy software house do systemu dla firmy?

Freelancer wystarczy przy małym, odizolowanym module albo prototypie. Przy systemie, na którym firma prowadzi rozliczenia, magazyn lub obieg zamówień, bezpieczniejszy jest zespół z procesem, dokumentacją i testami, bo wiedza o systemie nie zależy wtedy od jednej osoby.

Ile trwa stworzenie systemu na zamówienie?

W naszych projektach typowy system dedykowany to 4-12 tygodni od dokumentacji do wdrożenia, mniejsze funkcjonalności (kalkulator, formularz) 2-4 tygodnie, a duże systemy mogą trwać 3-6 miesięcy. Większe projekty wdraża się etapami, więc pierwsza działająca część zwykle pracuje w firmie na długo przed końcem całości.

Co się dzieje z systemem po zakończeniu gwarancji?

Możesz zostać przy wykonawcy w ramach płatnego utrzymania albo przejąć system i rozwijać go z innym zespołem. Warunkiem drugiej opcji są kod źródłowy, dokumentacja techniczna i testy przekazane w trakcie projektu, a nie dopiero na żądanie.

Jeśli porównujesz oferty na system dla swojej firmy, możemy przejść przez nie razem z Tobą według pytań z tego artykułu albo przygotować własną propozycję zaczynającą się od analizy procesu. Umów bezpłatną konsultację, NDA podpiszemy przed rozmową, jeśli tego potrzebujesz.