Jak wybrać firmę programistyczną?
Według Mesterséges Intelligencia Központ Kft., firmy programistycznej z Budapesztu, dobry wybór zależy od trzech pytań: czy wykonawca rozumie cel, czy jego ofertę można sprawdzić i do kogo po przekazaniu będą należeć kod i system.
W skrócie: najpierw proszę spisać cel i wymagania obowiązkowe, a dopiero potem prosić o oferty. Warto poprosić o pokazanie działających realizacji, przejrzysty proces i dostęp do kodu; oferty należy porównywać na podstawie tej samej specyfikacji pozycja po pozycji, najlepiej według zmierzonego rozmiaru. W umowie trzeba zapisać także kod źródłowy i prawa do korzystania, poufność, usuwanie błędów, eksploatację oraz sposób zakończenia współpracy.
Najpierw cel: co ma umieć oprogramowanie?
Większość złych wyborów zaczyna się nie od wykonawcy, lecz od niejasnego zlecenia. Jeśli nie spisano, co ma umieć oprogramowanie, każda oferta będzie oznaczać co innego i nie będzie do czego porównać ani ceny, ani gotowej pracy. Gotowa specyfikacja nie jest potrzebna (dobry wykonawca pomoże ją napisać), ale kilka rzeczy warto przemyśleć z wyprzedzeniem:
- Cel: jaki problem rozwiązuje oprogramowanie i po czym będzie widać, że odniosło sukces.
- Użytkownicy: kto będzie z niego korzystać: pracownicy firmy, klienci czy partnerzy.
- Wymagania obowiązkowe: to, bez czego nie można go uruchomić, oddzielone od pozycji z kategorii „byłoby dobrze, gdyby”.
- Istniejące systemy: z czym musi się łączyć (ERP, CRM, sklep internetowy, system do fakturowania, bank).
- Dane: jakie dane przetwarza, w tym także dane osobowe.
- Ramy: czy obowiązuje sztywny termin, wewnętrzne zasady, wymagania dotyczące hostingu lub bezpieczeństwa.
Warto też zdecydować, czy w ogóle potrzebne jest rozwiązanie na zamówienie, czy wystarczy gotowy produkt, ewentualnie gotowy produkt połączony z rozszerzeniem na zamówienie. Pomaga w tym artykuł Oprogramowanie na zamówienie czy gotowe rozwiązanie?.
Krótka lista: do kogo warto się zwrócić?
Nie trzeba zwracać się do wielu firm; kilku starannie wybranych kandydatów to lepiej niż wiele powierzchownych ofert. Kryteria zawężania listy:
- Podobne realizacje: czy firma zbudowała już system o podobnej wielkości i charakterze, na przykład oprogramowanie biznesowe, sklep internetowy, aplikację mobilną lub integrację AI.
- Dopasowanie technologiczne: czy pracuje z technologiami, z którymi muszą się łączyć istniejące systemy.
- Skala: czy moce przerobowe firmy pasują do projektu; duży system wymaga kilku specjalizacji, a małe zadanie mniej.
- Język i dostępność: czy może prowadzić uzgodnienia w Państwa języku i w Państwa strefie czasowej.
Sprawdzanie realizacji i referencji
Najmocniejszym dowodem jest działające oprogramowanie. Warto poprosić kandydatów, aby pokazali system, który można wypróbować, i dokładnie powiedzieli, jaki był w nim ich własny udział. Wiele prac dla klientów objętych jest poufnością, dlatego nie zawsze można podać nazwę. Wtedy wiele mówią też zanonimizowany opis, prezentacja lub własne produkty firmy.
Jeśli referencji udziela wcześniejszy zamawiający, warto zadawać konkretne pytania: czy dotrzymano uzgodnionego zakresu, jak obsługiwano zmiany i błędy, czy zamawiający otrzymał kod źródłowy i czy nadal współpracują. Ogólne „byliśmy zadowoleni” niewiele mówi; to, że zamawiający po przekazaniu nadal eksploatuje system razem z wykonawcą, mówi bardzo wiele.
Rozmowa techniczna
Z każdym kandydatem warto przeprowadzić rozmowę techniczną, najlepiej w obecności specjalisty technicznego także po Państwa stronie. Liczy się nie pewność siebie w odpowiedziach, lecz to, czy wykonawca zadaje pytania i nazywa ryzyka. Dobre pytania:
- Jak zabraliby się Państwo do pracy i co byłoby pierwszym etapem?
- Jak podłączyliby Państwo nasze istniejące systemy i co muszą Państwo o nich wiedzieć?
- Jak Państwo testują i kto decyduje, że dana część jest gotowa?
- Kto będzie pracował nad projektem i kto będzie naszą osobą kontaktową?
- Gdzie będzie działał system i kto odpowiada za aktualizacje bezpieczeństwa?
- Jeśli będzie w nim także sztuczna inteligencja: jakie dane trafią dokąd i co się stanie, gdy AI się pomyli?
Sygnałem ostrzegawczym jest sytuacja, gdy kandydat bez zadawania pytań, już po pierwszej rozmowie podaje dokładną cenę i termin.
Proces i komunikacja
W tworzeniu oprogramowania niespodzianki rzadko rodzą się w kodzie, znacznie częściej w komunikacji. Dlatego warto zapytać, jak będą Państwo widzieć postęp prac w trakcie realizacji. Cechy dobrej praktyki:
- Realizacja etapami: praca jest podzielona na etapy, a na koniec każdego z nich prezentowane jest działające oprogramowanie, a nie tylko sprawozdanie.
- Dostęp do kodu: zamawiający od pierwszego dnia widzi repozytorium kodu, a nie otrzymuje go dopiero przy przekazaniu.
- Przejrzysta lista zadań: zadania, błędy i zmiany są widoczne we wspólnym rejestrze.
- Stała osoba kontaktowa: jest ktoś, kto zna projekt i może podejmować decyzje.
- Zarządzanie zmianami: nowe lub zmienione wymaganie jest opisywane, mierzone lub szacowane i trafia do realizacji dopiero po zatwierdzeniu.
Porównanie ofert
Dwie oferty można porównać tylko wtedy, gdy dotyczą tego samego zakresu. Dlatego każdy kandydat powinien otrzymać ten sam opis pozycja po pozycji, a następnie proszę ich zapytać, dla jakich funkcji i jakiego rozmiaru podali cenę. Jeśli wykonawca mierzy rozmiar funkcjonalny oprogramowania metodą znormalizowaną, na przykład w punktach funkcyjnych COSMIC, rozmiar można sprawdzić na podstawie tej samej specyfikacji; metodę przedstawia artykuł Czym jest punkt funkcyjny COSMIC?.
Jeśli między dwiema ofertami jest duża różnica, warto zadać następujące pytania:
| Pytanie | Co pozwala ustalić |
|---|---|
| Dla jakiego rozmiaru i których funkcji podano cenę? | czy wyceniono ten sam zakres |
| Co jest ujęte jako osobna pozycja? | czy uwzględniono integrację, migrację danych, grafikę, eksploatację |
| Jakie wymagania niefunkcjonalne uwzględniono? | wydajność, bezpieczeństwo, dostępność cyfrowa |
| Jak obsługiwane są zmiany? | co się dzieje, gdy w trakcie prac pojawi się nowe wymaganie |
| Jakie są zasady usuwania błędów po przekazaniu? | co obejmuje wynagrodzenie, a co jest traktowane jako dodatkowa praca |
| Do kogo będzie należał kod źródłowy i jakie prawa otrzymamy? | czy system może dalej rozwijać ktoś inny |
| Czy rozliczenie odbywa się według ceny stałej, czy według nakładu pracy? | kto ponosi ryzyko związane z zakresem |
Cena stała sprawdza się dobrze, gdy zakres jest ustalony pozycja po pozycji; rozliczenie według nakładu pracy jest bardziej elastyczne, ale ryzyko związane z zakresem pozostaje po stronie zamawiającego. W obu przypadkach liczy się to, aby zakres był mierzalny i możliwy do śledzenia. Jak my wyceniamy, opisuje strona Wycena.
Najważniejsze postanowienia umowy
Umowa jest tym, co liczy się w razie sporu lub nieoczekiwanej sytuacji. Poniższe treści to informacja, a nie porada prawna: umowę warto przekazać do sprawdzenia także prawnikowi.
Kod źródłowy i prawa do korzystania
Węgierska ustawa o prawie autorskim (ustawa LXXVI z 1999 r., Szjt., w języku węgierskim) chroni program komputerowy, zarówno w postaci kodu źródłowego, jak i kodu wynikowego, jako utwór (§ 1 ust. 2 lit. c) i stanowi, że autorskie prawa majątkowe do oprogramowania są zbywalne (§ 58 ust. 3). Zamawiający nabywa więc albo autorskie prawa majątkowe, albo licencję na korzystanie; nie jest to to samo.
Kilka zasad, ze względu na które precyzyjne sformułowania są ważne: umowa licencyjna daje prawo wyłączne tylko wtedy, gdy zostało to wyraźnie zastrzeżone (§ 43 ust. 1); jeśli umowa nie określa sposobów i zakresu korzystania, licencja ogranicza się do zakresu niezbędnego do osiągnięcia celu umowy (§ 43 ust. 5); jeśli treść nie jest jednoznaczna, należy przyjąć wykładnię korzystniejszą dla autora (§ 42 ust. 3); a licencjobiorca może udzielić dalszej licencji osobie trzeciej tylko za wyraźną zgodą autora (§ 46 ust. 1). Dlatego warto zapisać:
- przekazanie pełnego kodu źródłowego i dokumentacji, także po każdym etapie;
- czy zamawiający nabywa autorskie prawa majątkowe, czy też otrzymuje licencję i w jakim zakresie: czy jest ona wyłączna, czy obejmuje prawo do modyfikacji i do dalszego przekazywania;
- że wykonawca dysponuje prawami do kodu napisanego przez jego pracowników i podwykonawców;
- wykaz wykorzystanych komponentów open source i komponentów pochodzących od osób trzecich wraz z ich licencjami.
Poufność (NDA)
Jeśli pomysł lub dane biznesowe są poufne, przed omówieniem szczegółów warto zawrzeć umowę o zachowaniu poufności (NDA). Warto w niej określić, co jest informacją poufną, kto może się z nią zapoznać, jak długo obowiązuje poufność i co dzieje się z materiałami po zakończeniu prac.
Usuwanie błędów i gwarancja
Umowa powinna określać, co uznaje się za błąd (odstępstwo od ustalonego wymagania), jak przebiegają testy odbiorowe, jakie istnieją poziomy ważności błędów i jak szybko wykonawca reaguje na każdym poziomie. Warto zapisać też, przez jaki czas wykonawca bezpłatnie usuwa błędy, które przy przekazaniu pozostały ukryte, i co jest już traktowane jako dalszy rozwój.
Eksploatacja i SLA
Jeśli wykonawca eksploatuje system także po przekazaniu, warunki określa umowa o poziomie usług (service level agreement, SLA): deklarowaną dostępność, sposób zgłaszania błędów, czasy reakcji i naprawy w zależności od wagi problemu, okna serwisowe, kopie zapasowe i raporty. Czego nie zapisano, tego w razie sporu nie można wyegzekwować.
Plan wyjścia
Plan wyjścia odpowiada na pytanie, co się stanie, jeśli współpraca z wykonawcą nie będzie kontynuowana, czy to z powodu niezadowolenia, czy z powodu zaprzestania działalności przez wykonawcę. Jego elementy:
- aktualna dokumentacja instalacji, architektury i eksploatacji;
- repozytorium kodu, hosting, domena i konta w chmurze zarejestrowane na zamawiającego lub przynajmniej z dostępem zamawiającego;
- zasady przekazywania haseł i kluczy dostępu;
- możliwość eksportu danych w standardowym formacie;
- współpraca przy przekazaniu systemu nowemu wykonawcy.
Ochrona danych: umowa powierzenia przetwarzania danych
Jeśli wykonawca podczas pracy ma dostęp do danych osobowych, bo na przykład eksploatuje system lub testuje na danych produkcyjnych, zgodnie z RODO zazwyczaj jest podmiotem przetwarzającym i trzeba zawrzeć z nim pisemną umowę powierzenia przetwarzania danych (art. 28 RODO). Musi ona określać m.in., że wykonawca przetwarza dane wyłącznie na udokumentowane polecenie zamawiającego, zapewnia poufność i bezpieczeństwo, korzysta z usług innego podmiotu przetwarzającego tylko za zgodą, po zakończeniu świadczenia usługi usuwa lub zwraca dane oraz umożliwia przeprowadzanie audytów.
Praktyka w zakresie bezpieczeństwa
Bezpieczeństwa nie da się dodać do oprogramowania na końcu, dlatego warto zapytać, jak wykonawca dba o nie w swojej pracy. Dobrym punktem wyjścia jest OWASP Top 10, szeroko znana lista najbardziej krytycznych zagrożeń bezpieczeństwa aplikacji webowych; aktualnym wydaniem jest OWASP Top 10:2025 (sprawdzono 17 października 2026 r.). Na pierwszych trzech miejscach znajdują się: niewłaściwa kontrola dostępu, błędna konfiguracja zabezpieczeń oraz błędy w łańcuchu dostaw oprogramowania. Proszę zapytać:
- Jak zarządzają Państwo uprawnieniami i jak testują Państwo, czy użytkownik widzi wyłącznie własne dane?
- Jak aktualizują Państwo wykorzystywane biblioteki zewnętrzne i skąd wiedzą Państwo, że któraś z nich ma podatność?
- Gdzie przechowują Państwo hasła i klucze i kto ma do nich dostęp?
- Czy stosują Państwo przegląd kodu (code review) i testy automatyczne?
- Jak tworzone są kopie zapasowe i czy próbowali już Państwo przywrócić dane z kopii?
Freelancer czy firma programistyczna?
Obie opcje mogą być dobrym wyborem; pytanie brzmi, jak duże jest zadanie i jak długo system będzie działał.
| Kryterium | Freelancer | Firma programistyczna |
|---|---|---|
| Komunikacja | bezpośrednia, z jedną osobą | przez osobę kontaktową, z kilkoma specjalistami |
| Specjalizacje | wiedza jednej osoby | kilka specjalizacji: interfejs, backend, aplikacje mobilne, eksploatacja, testy |
| Zastępowalność | w razie choroby lub odejścia praca staje | członkowie zespołu mogą przejmować nawzajem swoją pracę |
| Moce przerobowe | do mniejszych, dobrze określonych zadań | do większych systemów i pracy równoległej |
| Umowa | bezpośrednio ze specjalistą | z firmą, która odpowiada za pracę zespołu |
| Długoterminowa eksploatacja | zależy od dostępności freelancera | można ją zapewnić w zorganizowany sposób |
Freelancer dobrze sprawdza się przy dobrze określonym zadaniu, zwłaszcza jeśli zamawiający ma własnego kierownika technicznego, który kieruje pracą i ją odbiera. Jeśli system jest częścią codziennego funkcjonowania firmy, wymaga kilku specjalizacji i będzie działał przez lata, firma programistyczna oznacza zazwyczaj mniejsze ryzyko. Plan wyjścia i przekazanie kodu źródłowego są w obu przypadkach równie ważne.
Sygnały ostrzegawcze
- Dokładna cena i termin już po pierwszej rozmowie, bez żadnych pytań.
- Brak pisemnej specyfikacji albo oferta, z której nie wynika, czego dotyczy.
- Zamawiający nie może oglądać kodu, otrzymałby go dopiero przy przekazaniu.
- Wymijająca odpowiedź na pytanie, kto będzie pracował nad projektem.
- Niejasne, do kogo będzie należał kod źródłowy i jakie prawa otrzyma zamawiający.
- Odmowa zawarcia umowy powierzenia przetwarzania danych lub umowy o zachowaniu poufności.
- Brak działających realizacji, które można pokazać.
Lista kontrolna
| Pytanie | W porządku, jeśli |
|---|---|
| Czy cel i wymagania obowiązkowe są spisane? | istnieje krótki opis, który wszyscy rozumieją tak samo |
| Czy widzieliśmy działającą realizację? | wypróbowaliśmy co najmniej jeden podobny system |
| Czy rozumieją zadanie? | zadawali pytania i nazwali ryzyka |
| Czy będziemy widzieć postęp? | prezentacje po etapach, dostęp do repozytorium kodu |
| Czy ofertę można porównać? | dotyczy tego samego zakresu opisanego pozycja po pozycji, a osobne pozycje są widoczne |
| Czy kwestia kodu źródłowego i praw jest uregulowana? | umowa określa przekazanie i zakres praw |
| Czy jest umowa o zachowaniu poufności i umowa powierzenia przetwarzania danych? | tam, gdzie to potrzebne, zostały podpisane |
| Czy usuwanie błędów i eksploatacja są uregulowane? | poziomy ważności, czasy reakcji, SLA |
| Czy jest plan wyjścia? | dokumentacja, dostępy, eksport danych |
| Czy zapytaliśmy o bezpieczeństwo? | konkretne odpowiedzi dotyczące uprawnień, aktualizacji, kopii zapasowych |
Częste pytania
Freelancer czy firma programistyczna?
Przy dobrze określonym, mniejszym zadaniu dobrym wyborem może być także doświadczony freelancer, zwłaszcza jeśli firma ma własnego kierownika technicznego. Jeśli system jest częścią codziennego funkcjonowania, wymaga kilku specjalizacji i będzie długo działał, firma programistyczna oznacza mniejsze ryzyko, ponieważ praca nie zależy od jednej osoby.
Jak porównać dwie oferty cenowe?
Porównywać można tylko oferty przygotowane dla tej samej specyfikacji pozycja po pozycji. Proszę zapytać obu oferentów, dla jakiego rozmiaru i których funkcji podali cenę, co jest ujęte jako osobna pozycja i jak obsługują zmiany. Jeśli rozmiar zmierzono metodą znormalizowaną, na przykład w punktach funkcyjnych COSMIC, można go sprawdzić na podstawie tej samej specyfikacji.
Co powinna zawierać umowa?
Zakres (specyfikację pozycja po pozycji), cenę i harmonogram, przekazanie kodu źródłowego i zakres praw do korzystania, poufność, zasady odbioru i usuwania błędów, eksploatację i SLA, plan wyjścia, a jeśli w grę wchodzą dane osobowe, także umowę powierzenia przetwarzania danych. To informacja, a nie porada prawna.
Co się stanie, jeśli wykonawca zniknie?
Jeśli kod źródłowy, dokumentacja i dostępy są u zamawiającego, system może przejąć inny wykonawca. Dlatego warto od pierwszego dnia mieć wgląd w repozytorium kodu, utrzymywać hosting i domenę zarejestrowane na własną firmę oraz zapisać w umowie plan wyjścia. Jeśli tego brakuje, dalsze prowadzenie systemu może być trudne i powolne.
Do kogo będzie należał kod źródłowy?
Do tego, komu przysługuje zgodnie z umową: według węgierskiej ustawy o prawie autorskim autorskie prawa majątkowe do oprogramowania są zbywalne, ale nie dzieje się to automatycznie. W umowie warto zapisać, że zamawiający otrzymuje pełny kod źródłowy, i dokładnie określić, jakie prawa do niego nabywa. U nas również kwestie kodu źródłowego i praw do korzystania reguluje umowa.
Jak możemy pomóc?
Tak pracujemy: pierwsza konsultacja jest bezpłatna, specyfikację piszemy wspólnie, rozmiar oprogramowania mierzymy w punktach funkcyjnych COSMIC, a na tej podstawie powstają oferta i harmonogram. Realizacja przebiega etapami, z prezentacją na koniec każdego etapu; na życzenie zawieramy umowę o zachowaniu poufności (NDA), a po przekazaniu zapewniamy również eksploatację i utrzymanie. Kwestie kodu źródłowego i praw do korzystania reguluje umowa. Kolejne kroki opisuje strona Jak pracujemy, a metodę wyceny przedstawia strona Wycena.
Obecnie tworzymy duży system ERP i CRM; nasze własne realizacje, które można wypróbować, przedstawiamy na stronie Nasze realizacje, o firmie można przeczytać na stronie O nas, a odpowiedzi na częste pytania znajdą Państwo na stronie Częste pytania. Jeśli szukają Państwo wykonawcy, prosimy do nas napisać, korzystając z danych kontaktowych podanych na stronie Kontakt.