Dlaczego wybór wykonawcy to 80% sukcesu projektu
Nieudane projekty IT rzadko upadają przez technologię. Najczęściej przez źle dobranego partnera: brak zrozumienia biznesu, chaotyczną komunikację i zakres, który rośnie bez kontroli, aż budżet kończy się w połowie drogi.
Rynek jest szeroki — od jednoosobowych freelancerów po kilkusetosobowe firmy. Ceny potrafią różnić się kilkukrotnie przy pozornie tym samym zakresie, a różnica prawie nigdy nie bierze się z chciwości, tylko z tego, że każdy wycenia co innego.
Ten przewodnik to lista rzeczy, które warto sprawdzić, zanim podpiszesz umowę.
Cztery typy wykonawców i kiedy który ma sens
Freelancer
Najtaniej i najszybciej przy małym, dobrze zdefiniowanym zadaniu. Ryzyko: jedna osoba to jeden punkt awarii — choroba, inny projekt albo zmiana pracy zatrzymują wszystko. Rzadko obejmuje design, backend i utrzymanie naraz.
Mały software house
Zespół 5–30 osób. Obsługuje projekt end-to-end, a rozmawiasz zwykle z osobami, które faktycznie przy nim pracują. Ograniczenie: mniejsza odporność na kilka dużych projektów naraz.
Duża firma
Zasoby, procesy i odporność na rotację. Kosztuje więcej, a Twój projekt bywa jednym z wielu — z mniejszym priorytetem, jeśli nie jest największy w portfelu.
Pośrednik
Firma, która przyjmuje zlecenie i oddaje je podwykonawcy. Bywa sensowna, ale musisz o tym wiedzieć — zapytaj wprost, kto pisze kod i gdzie ten zespół siedzi.
Na co patrzeć w portfolio
Realne wdrożenia, nie makiety
Proś o linki do działających produktów i efekty w liczbach, nie tylko screeny z Behance. Zobacz dla porównania, jak my pokazujemy nasze realizacje — z zakresem, technologiami i wynikami.
Projekty podobne do Twojego
Firma, która zbudowała pięć systemów rezerwacji, szósty zrobi szybciej, taniej i ominie pułapki, o których inni jeszcze nie wiedzą.
Stack, który da się utrzymać
Popularne technologie (React, Node.js, React Native) oznaczają, że w przyszłości łatwo znajdziesz programistów do rozwoju — nie jesteś skazany na jednego dostawcę.
Referencje z kontaktem
Dobry software house bez wahania poda Ci klienta, do którego możesz zadzwonić i zapytać, jak wyglądała współpraca naprawdę.
7 pytań na pierwsze spotkanie
Odpowiedzi na te pytania powiedzą Ci o firmie więcej niż każda prezentacja sprzedażowa:
Kto będzie realnie pracował przy moim projekcie? — Zespół z prezentacji sprzedażowej i zespół z projektu to częsty rozjazd. Poproś o poznanie osób, które faktycznie będą pisać kod.
Jak wygląda proces od pomysłu do wdrożenia? — Szukaj konkretów: warsztat, makiety, iteracje, testy, wdrożenie. Brak jasnego procesu to zapowiedź chaosu.
Jak często będę widzieć postępy? — Dobra odpowiedź: działające demo co 1–2 tygodnie. Zła: „pokażemy całość na koniec".
Co się stanie, gdy zakres się zmieni? — Zakres ZAWSZE się zmienia. Uczciwa firma opisze proces wyceny zmian, a nie obieca, że „nic się nie stanie".
Kto jest właścicielem kodu? — Kod, repozytorium i dostępy powinny być Twoje — zapisane wprost w umowie, nie „do ustalenia później".
Jak wygląda utrzymanie po wdrożeniu? — Produkt bez opieki umiera. Zapytaj o czas reakcji, stawki utrzymaniowe i to, kto odbiera telefon, gdy coś padnie.
Dlaczego akurat ta technologia? — Dobra firma uzasadnia wybór stacku Twoim projektem i Twoim budżetem — nie tym, w czym akurat ma wolnych ludzi.
Jak czytać wycenę
Wycena z jedną liczbą jest nieporównywalna z żadną inną. Rzetelna oferta rozbija koszt na etapy i wprost wymienia założenia, na których stoi.
Stała cena ma sens przy mniejszym, dobrze określonym zakresie. Wiadomo, co powstaje, więc da się to uczciwie wycenić.
Rozliczenie za czas jest właściwe przy dłuższych projektach. Stała cena na kilkumiesięczny system oznacza albo gruby bufor na ryzyko wliczony w kwotę, albo negocjowanie aneksu przy pierwszej zmianie zakresu. Warunkiem jest regularny wgląd w postęp — działające demo co jeden–dwa tygodnie.
Uwaga na ofertę wyraźnie tańszą od pozostałych. Zwykle oznacza węższy zakres ukryty w założeniach, brak testów albo doliczanie jako prac dodatkowych wszystkiego, co nie zostało wprost wymienione. Różnicę zapłacisz później, już bez pola do negocjacji.
Sześć rzeczy, które muszą być w umowie
Nie jako formalność — każdy z tych punktów rozwiązuje spór, który realnie się zdarza:
Przeniesienie praw do kodu — Prawa majątkowe powinny przechodzić na Ciebie, wprost, wraz z zapłatą za dany etap. Nie „do ustalenia po zakończeniu projektu”.
Dostępy po Twojej stronie — Repozytorium, hosting, domena i konta w sklepach powinny być zakładane na Twoje dane. Odzyskiwanie ich później od byłego wykonawcy potrafi trwać miesiącami.
Opisany zakres — Konkretna lista tego, co powstaje. Bez niej każda rozmowa o tym, co miało być zrobione, jest słowem przeciwko słowu.
Proces zmiany zakresu — Zakres zawsze się zmienia. Umowa ma opisywać, jak zmiana jest wyceniana i zatwierdzana — a nie obiecywać, że zmian nie będzie.
Gwarancja — Co obejmuje, jak długo trwa i czym różni się błąd objęty gwarancją od nowej funkcji. To najczęstsze pole sporu po wdrożeniu.
Zasady zakończenia współpracy — Okres wypowiedzenia i to, co dostajesz na wyjściu: kod, dokumentację, dostępy i przekazanie wiedzy. Sprawdzasz ten zapis wtedy, gdy jest już źle.
Trzy pytania techniczne, które warto zadać, nawet nie będąc technicznym
„W jakich technologiach to zbudujecie i dlaczego akurat w tych?" Szukasz uzasadnienia opartego na Twoim projekcie, nie na tym, co firma lubi. Popularne technologie — React, Node.js, React Native — oznaczają, że w przyszłości znajdziesz innych programistów. Niszowy wybór potrafi Cię przywiązać do jednego wykonawcy na lata.
„Co się stanie z projektem, jeśli przestaniemy współpracować?" Dobra odpowiedź opisuje przekazanie: repozytorium, dokumentacja, dostępy, spotkanie z nowym zespołem. Odpowiedź wymijająca to sygnał ostrzegawczy sam w sobie.
„Kto będzie utrzymywał to po wdrożeniu i na jakich zasadach?" Produkt bez opieki umiera — aktualizacje systemów, biblioteki, poprawki bezpieczeństwa. Zapytaj o czas reakcji, stawki i o to, kto faktycznie odbiera zgłoszenie o drugiej w nocy.
Sygnały ostrzegawcze
Niezależnie od tego, jak dobrze wypada firma na spotkaniu — przy tych sygnałach zachowaj czujność:
Wycena bez zadawania pytań
Nikt nie jest w stanie rzetelnie wycenić aplikacji po jednym mailu. Szybka „wycena z powietrza" oznacza, że prawdziwy koszt poznasz w trakcie projektu.
„Wszystko się da, żaden problem"
Brak pytań o priorytety i kompromisy oznacza, że zakres i budżet popłyną. Dobry partner mówi też „nie" i proponuje tańsze alternatywy.
Brak umowy opisującej zakres
Praca „na zaufanie" kończy się sporem o to, co miało być zrobione. Zakres, harmonogram i zasady zmian muszą być na piśmie.
Kontakt tylko przez handlowca
Jeśli przed podpisaniem umowy nie możesz porozmawiać z nikim technicznym, po podpisaniu też nie będzie łatwiej.
Porównujesz oferty software house'ów?
Prześlij nam swój brief — pokażemy, jak podeszlibyśmy do projektu, jakim zespołem i za ile. Bez zobowiązań, w ciągu 24 godzin.
Lokalnie czy zdalnie?
Dobra wiadomość: to nie jest wybór „albo–albo". Współpraca z firmą z okolic Poznania daje możliwość spotkania na żywo przy kluczowych etapach — warsztacie discovery, ważnych odbiorach czy planowaniu kolejnych faz — podczas gdy codzienna praca i tak toczy się online, w krótkich iteracjach z regularnymi demo.
Nasze biuro znajduje się w Dąbrówce, kilkanaście minut od zachodnich granic Poznania, więc spotkanie przy kawie to u nas standard, nie wyjątek. Więcej o tym, jak pracujemy z firmami z regionu, przeczytasz na stronie software house Poznań, a nasze wdrożenia zobaczysz w realizacjach.
Najczęściej zadawane pytania
Ile kosztują usługi software house'u w Poznaniu?+
Software house czy freelancer?+
Czy muszę być z Poznania, żeby współpracować z Just Site?+
Software house czy freelancer — co wybrać?+
Czy muszę znać się na technologii, żeby dobrze wybrać?+
Ile powinna trwać wycena?+
Czy warto wybierać wykonawcę z okolicy?+
Masz pomysł na projekt?
Pomożemy go zaprojektować i wdrożyć, od strategii po gotowe rozwiązanie.
