Zanim zaczniesz rozmowy z software house, warto przygotować kilka pytań, które szybko odsłonią ryzyka: budżet, termin, jakość i kontrolę nad kodem. Ta checklista pomoże Ci odróżnić konkrety od ogólników i uniknąć sytuacji, w której „wycena” i „plan” istnieją tylko w prezentacji.
Najważniejsze wnioski z artykułu
- Dobra wycena projektu IT zawsze ma założenia, wyłączenia i opis zakresu.
- Termin to nie „data na slajdzie”, tylko harmonogram projektu IT z etapami i punktami kontrolnymi.
- Najmniej boli współpraca, gdy masz stały rytm demo, jasne statusy i dostęp do repo od dnia 1.
- Vendor lock-in zaczyna się od braku dokumentacji, repozytorium i planu przekazania projektu.
- Bezpieczeństwo (RODO, backupy, incydenty) trzeba omówić przed startem, nie po wdrożeniu.
Zanim podpiszesz umowę, zadaj te pytania (i sprawdź, czy odpowiedzi są konkretne, a nie „marketingowe”)
Dobre pytania do software house działają jak filtr: w 20–30 minut zobaczysz, czy rozmawiasz z partnerem, który rozumie ryzyka projektu, czy z handlowcem od „ładnych slajdów”. Klucz jest prosty: proś o przykłady, liczby i artefakty (zakres, harmonogram, backlog, repo, standardy jakości), bo to one pokazują, jak firma naprawdę prowadzi projekt.
Ustal zasadę „konkret albo czerwone światło”. Konkret to: rozpisana wycena projektu IT z założeniami i wyłączeniami, realny plan iteracji, jasny proces komunikacji oraz odpowiedzialność po obu stronach. Marketing to: „zrobimy szybko”, „mamy doświadczenie”, „u nas jest Agile” — bez pokazania, jak wygląda to w praktyce i co dokładnie dostajesz.
Ile będzie kosztować mój projekt i co dokładnie zawiera ta wycena (a czego nie)?
Zapytaj o koszt stworzenia aplikacji w rozbiciu na etapy (discovery, UX/UI, development, QA, wdrożenie) oraz o to, co jest „poza ceną”. Dobra wycena projektu IT ma listę założeń i wyłączeń: integracje, migracje danych, content, licencje, analitykę czy DevOps.
Dopytaj też o model: time and material vs fixed price. Przy MVP zwykle wygrywa T&M z kontrolą kosztu (cap, milestone’y, stop/continue), bo zakres zmienia się po feedbacku. Jeśli chcesz zobaczyć, jak to wygląda w praktyce przy mobile to sprawdź projektowanie aplikacji mobilnych z Selleo.
Ile potrwa realizacja i jak wygląda harmonogram od analizy do wdrożenia?
Nie pytaj tylko „ile to potrwa?”, tylko poproś o harmonogram projektu IT: kiedy kończy się analiza, kiedy jest prototyp, kiedy pierwsze demo, kiedy wdrożenie i stabilizacja. To pozwala ocenić realny time to market, a nie deklarację „zrobimy szybko”.
Warto ustalić, jak software house planuje ryzyka: opóźnienia zależne od klienta (decyzje, materiały, dostęp do systemów) oraz bufor na testy i poprawki. Jeśli chcesz porównać profesjonalne podejście do startu i onboardingu, sprawdź usługi Software House Selleo.
Jak będzie wyglądać współpraca na co dzień: komunikacja, statusy, spotkania i raportowanie postępów?
Dobra współpraca z software house to rytm i transparentność: demo co 1–2 tygodnie, krótkie statusy, jasne decyzje po spotkaniach. Poproś o przykład raportu tygodniowego: co dowiezione, co zablokowane, jakie ryzyka i co jest planem na kolejny sprint.
Zapytaj o narzędzia i artefakty: backlog, Definition of Done, dostęp do Jira/Linear, repo Git, standardy code review i CI/CD. Jeśli temat dotyczy produktu edukacyjnego (role, raporty, treści), to świetnym punktem odniesienia będzie tworzenie Learning Experience Platform z Selleo.
W jakiej technologii to zrobicie i jak mogę uniknąć uzależnienia od jednego wykonawcy (vendor lock-in)?
Poproś o uzasadnienie doboru technologii: jaki będzie stack technologiczny aplikacji, jak rozwiązujecie integracje (API-first), wdrożenia (CI/CD) i skalowanie (cloud-native). Sama nazwa frameworka to za mało — liczy się utrzymanie, testowalność i koszt rozwoju.
Dopytaj wprost o vendor lock-in: czy dostaniesz repo od dnia 1, czy dokumentacja jest częścią procesu, jak wygląda przekazanie projektu i dostępów (exit plan). Jeśli pracujesz w EdTech’u i wchodzą wymagania typu role, raportowanie czy compliance, przydatny kontekst znajdziesz na stronie oprogramowanie dla edukacji z Software House Selleo.
Jak zabezpieczacie dane i jak podchodzicie do RODO / backupów / incydentów bezpieczeństwa?
Zapytaj o bezpieczeństwo aplikacji webowej na poziomie praktyk: OWASP, szyfrowanie, polityka uprawnień, logowanie zdarzeń (audit trail) oraz proces obsługi incydentów (incident response). Przy danych wrażliwych dopytaj o zgodność z RODO w projekcie IT i miejsce przetwarzania danych.
Koniecznie porusz temat backup i disaster recovery: RPO/RTO, retencja, testy odtwarzania oraz monitoring i alerting. Jeśli potrzebujesz też utrzymania, doprecyzuj SLA (czasy reakcji, okna serwisowe, odpowiedzialność). W branży Human Resources (dane osobowe, role, dostęp) sensownym partnerem do współpracy jest HRM software od Selleo.
Czy kod i repozytorium będą moją własnością i jak rozwiązujecie kwestie NDA oraz licencji?
To pytanie domyka kontrolę. Ustal własność kodu źródłowego i repozytorium: kto jest właścicielem kont, kto ma uprawnienia admin, jak wygląda przeniesienie praw i przekazanie dokumentacji. Dopytaj o umowę z software house: przeniesienie praw majątkowych, pola eksploatacji, zasady użycia komponentów open source.
Na koniec NDA: czy podpisujecie NDA projekt IT, jak chronione są materiały i dostęp do środowisk. Dobrą praktyką jest spisanie „exit planu” wprost w umowie — wtedy prawa autorskie do oprogramowania i przekazanie projektu nie są tematem „na później”, tylko częścią ustaleń od startu.
materiał partnera