Jak wybrać firmę do stworzenia aplikacji webowej: 10 pytań przed umową i wzór specyfikacji

Krótka odpowiedź: wyślij kilku wykonawcom ten sam opis zakresu i zadaj im te same pytania, a odpowiedzi zbierz na piśmie. Porównujesz wtedy oferty, a nie wrażenie z rozmowy. Najwięcej mówią odpowiedzi o pierwszej wersji (co i kiedy), stałości ceny, dostępie do kodu i danych, miejscu hostingu i koszcie utrzymania. Niżej jest 10 pytań z tym, jak brzmi dobra odpowiedź, oraz wzór specyfikacji do pobrania.

Zanim zaczniesz pytać: jeden opis dla wszystkich

Oferty da się porównać tylko wtedy, gdy każdy wykonawca wycenia to samo. Wystarczy opis jednego dnia pracy: kto uczestniczy w procesie, gdzie dziś są informacje i co się psuje. Do tego trzy do pięciu rzeczy, bez których program nie ma sensu, i lista tego, co może poczekać.

Dobry wykonawca zada potem własne pytania o proces. Jeśli nikt nie pyta, jak wygląda Wasz dzień pracy, a wycena przychodzi po kwadransie rozmowy, cena dotyczy programu, który ktoś sobie wyobraził. Wykonawca powinien też umieć powiedzieć, że program nie ma sensu, bo czasem wystarczy arkusz albo automat — o tym jest tekst jak przejść z Excela na program w firmie.

10 pytań do wykonawcy przed umową

Przy każdym pytaniu jest dobra odpowiedź, sygnał ostrzegawczy i to, jak robimy to w Nexivio — żeby było z czym porównać.

1. Co dokładnie dostaniemy w pierwszej wersji i kiedy?
2. Czy cena jest stała i co może ją zmienić?
3. Ile kosztuje utrzymanie po wdrożeniu i co obejmuje?
4. Kto będzie miał dostęp do kodu i dokumentacji i jak zapiszemy to w umowie?
5. Gdzie będą stały dane, jak działają kopie zapasowe i jak je wyeksportujemy?
6. Kto będzie widział jakie dane i czy podpiszemy umowę powierzenia (RODO)?
7. Kto konkretnie prowadzi projekt i z kim rozmawiamy na co dzień?
8. Czego potrzebujecie od nas na start?
9. Jak przejdziemy z obecnego narzędzia bez przestoju?
10. Czy możemy zobaczyć działający system o podobnej skali?

Zakres i cena

1. Co dokładnie dostaniemy w pierwszej wersji i kiedy?

Dobra odpowiedź: lista ekranów i funkcji pierwszej wersji z datą oraz informacja, że przetestujecie ją na własnych danych.

Sygnał ostrzegawczy: pierwszy działający program dopiero na koniec projektu, po kilku miesiącach.

U nas: CRM w 5–7 dni roboczych, panel lub aplikacja w 2–4 tygodnie, testy na Waszych danych — szerzej w tekście MVP aplikacji dla firmy.

2. Czy cena jest stała i co może ją zmienić?

Dobra odpowiedź: cena stała przy niezmienionym zakresie, a każda zmiana zakresu wyceniona na piśmie przed wykonaniem.

Sygnał ostrzegawczy: stawka godzinowa bez limitu przy niejasnym zakresie albo cena podana bez pytań o proces.

U nas: zakres, harmonogram i cena na piśmie w 3–5 dni od rozmowy; cena jest stała, jeśli nie zmienia się zakres.

3. Ile kosztuje utrzymanie po wdrożeniu i co obejmuje?

Dobra odpowiedź: kwota miesięczna albo zasady zleceń jednorazowych i lista, co obejmuje: monitoring, poprawki błędów, kopie zapasowe, aktualizacje. Osobno warto policzyć hosting i usługi zewnętrzne, z których program korzysta.

Sygnał ostrzegawczy: „zobaczymy po wdrożeniu”.

U nas: opieka od 500 PLN netto miesięcznie albo zmiany zlecane jednorazowo — szczegóły w cenniku.

Kod, dane i dostęp

4. Kto będzie miał dostęp do kodu i dokumentacji i jak zapiszemy to w umowie?

Dobra odpowiedź: konkretny zapis w umowie: przeniesienie autorskich praw majątkowych z wymienionymi polami eksploatacji (art. 41 ust. 2 ustawy o prawie autorskim) albo licencja z jasno opisanym zakresem, do tego dostęp do repozytorium i dokumentacji technicznej. Przeniesienie praw wymaga umowy w formie pisemnej pod rygorem nieważności (art. 53 ustawy o prawie autorskim), czyli z podpisem własnoręcznym albo kwalifikowanym podpisem elektronicznym — mail czy kliknięcie w ofercie nie wystarczą.

Sygnał ostrzegawczy: kod tylko u wykonawcy i brak zapisu w umowie.

U nas: dostęp do kodu i dokumentacji zapisujemy w umowie przed startem.

5. Gdzie będą stały dane, jak działają kopie zapasowe i jak je wyeksportujemy?

Dobra odpowiedź: konkretny kraj albo region serwerów, częstotliwość kopii zapasowych i sposób ich odtworzenia oraz eksport danych w otwartym formacie, np. CSV.

Sygnał ostrzegawczy: „dane są bezpieczne” bez szczegółów.

U nas: hosting w Polsce lub w UE; kopie zapasowe i eksport ustalamy w umowie.

6. Kto będzie widział jakie dane i czy podpiszemy umowę powierzenia (RODO)?

Dobra odpowiedź: role dostępu ustalone przed startem i kontrola dostępu po stronie danych, a nie tylko ukryty przycisk na ekranie. Jeśli program przetwarza dane osobowe w Waszym imieniu, potrzebna jest umowa powierzenia przetwarzania (art. 28 RODO).

Sygnał ostrzegawczy: jedno konto dla wszystkich.

U nas: role i umowa powierzenia są w umowie; w obiegu dokumentów RAN-SIGMA dokument spoza zakresu roli w ogóle nie wraca z zapytania.

Sposób pracy

7. Kto konkretnie prowadzi projekt i z kim rozmawiamy na co dzień?

Dobra odpowiedź: imię i nazwisko osoby, która prowadzi projekt i odpowiada za decyzje techniczne, oraz ustalenie, kto po Waszej stronie zatwierdza.

Sygnał ostrzegawczy: przed umową rozmawiasz tylko ze sprzedawcą, a osób, które zbudują program, nie poznajesz.

U nas: projekty prowadzi Jarosław Pacek.

8. Czego potrzebujecie od nas na start?

Dobra odpowiedź: krótka lista: opis procesu, osoba decyzyjna, próbka danych, dostępy.

Sygnał ostrzegawczy: wykonawca niczego nie potrzebuje, bo wszystko „ustali w trakcie”.

U nas: opis jednego dnia pracy, jedna osoba, która decyduje, i przykładowe dane — tak jak w opisie jak pracujemy.

9. Jak przejdziemy z obecnego narzędzia bez przestoju?

Dobra odpowiedź: plan importu danych i okres, w którym dotychczasowy arkusz i nowy program działają obok siebie, a wyniki się porównuje.

Sygnał ostrzegawczy: „od poniedziałku przechodzicie na nowy system” bez okresu przejściowego.

U nas: kilka tygodni pracy równoległej; krok po kroku opisuje to tekst jak przejść z Excela na program.

Dowody

10. Czy możemy zobaczyć działający system o podobnej skali?

Dobra odpowiedź: realizacja z datą wdrożenia i opisem tego, co działa. Zrzuty mogą być na danych fikcyjnych, bo dane innych klientów są poufne.

Sygnał ostrzegawczy: same makiety i ogólniki, bez dat.

U nas: realizacje z harmonogramem i datą startu, ze zrzutami w wersji demo albo z podpisanymi makietami.

Źródła: ustawa o prawie autorskim i prawach pokrewnych (art. 41 ust. 2 i art. 53), Kodeks cywilny (art. 78¹ — forma elektroniczna), RODO (art. 28) (odczyt 18 października 2026). To nie jest porada prawna — treść umowy warto skonsultować z prawnikiem.

Wzór specyfikacji do pobrania

Plik DOCX do wypełnienia i wysłania wykonawcom. Ma siedem części opisu i tabelę do porównania odpowiedzi na pytania z tego tekstu:

1. Firma i cel — w tym, po czym po trzech miesiącach poznacie, że program działa.
2. Proces dziś — opis jednego dnia pracy.
3. Użytkownicy i role — kto co widzi i co zatwierdza.
4. Zakres pierwszej wersji i rzeczy na później.
5. Dane i integracje — skąd dane przychodzą i dokąd mają trafiać.
6. Wymagania — praca bez internetu, lokalizacja serwerów, dane osobowe, kopie zapasowe i eksport.
7. Terminy, budżet i osoba decyzyjna.
8. Tabela porównania odpowiedzi trzech wykonawców na 10 pytań.

Pobierz wzór specyfikacji (DOCX, 39 KB)

Plik otworzysz w Wordzie, Google Docs i Pages. Można go dowolnie kopiować i zmieniać.

Najczęstsze pytania