Agencja, software house czy freelancer. Kogo wybrać do zbudowania aplikacji?

Firma tworząca aplikacje czy freelancer

Ile może kosztować opracowanie aplikacji możesz sprawdzić w tym artykule. Jednak większość porównań dotyczących wyboru wykonwacy zaczyna się od „ile osób pracuje nad projektem". To zła oś. Lepsze pytanie brzmi: co dokładnie jest w cenie.

Freelancer to sam kod. Jedna osoba, która pisze, testuje, wdraża i sama sobie odpowiada za jakość Twojej aplikacji. Dlatego jest taniej. W około 90% przypadków freelancer wyceni projekt niżej niż software house, i to nie dlatego, że robi to gorzej, tylko dlatego, że nie ma za sobą biura, zespołu specjalistów ani licencji do opłacenia.

Software house to kod plus proces. Dostajesz zorganizowany zespół: doświadczonych programistów, project managera, testerów, często UX designera. Praca idzie w zwinnej metodyce, w iteracjach co dwa tygodnie widzisz postęp, a za jakość odpowiada nie jedna osoba, tylko struktura.

Agencja to kod plus proces plus myślenie produktowe. I tu piszę już o tym, jak sami pracujemy. Do tego wszystkiego, co daje dobry software house, dochodzi partnerstwo w decyzjach produktowych i wykorzystanie AI, które skraca czas i koszt budowy. Nie jako hasło marketingowe, tylko jako sposób pracy, który sprawdziliśmy na własnym produkcie. O tym, jak budujemy produkty z AI, możesz sprawdzić tutaj: BB8: AI development.

Trzy modele, trzy różne rzeczy w cenie. Najtańszy nie jest gorszy sam w sobie. Po prostu kupujesz mniej.

Kiedy najtańsza opcja wychodzi najdrożej przy budowaniu aplikacji mobilnych

Tu robi się nieprzyjemnie, więc powiem wprost. Najniższa oferta na starcie potrafi być najdroższa na mecie. Nie dlatego, że wykonawca chce cię oszukać, tylko dlatego, że kupujesz mniej zabezpieczenia. A software ma to do siebie, że brak zabezpieczenia lubi się ujawnić w najgorszym momencie.

Pierwszy scenariusz: znika jedna osoba. Przy pojedynczym freelancerze nie ma drugiej pary oczu i nie ma zastępstwa. Choroba, nagła rezygnacja, wypalenie i zostajesz z niedokończonym kodem, którego nikt inny nie zna. W zarządzaniu ryzykiem nazywa się to „bus factor". Software house tego problemu nie ma, bo ciągłość zapewnia zespół, a nie człowiek.

Drugi scenariusz: musisz zmienić wykonawcę w trakcie. Przejęcie nieudokumentowanego projektu po kimś innym potrafi kosztować od 30 do 50 procent wartości pierwotnego zlecenia. Do tego dochodzi dług technologiczny, który przy niekontrolowanym rozroście zjada nawet 40% budżetu IT. Płacisz drugi raz za to samo, tylko drożej.

I żeby było jasne, jak duża to skala: tylko 31% % projektów IT kończy się pełnym sukcesem. Reszta przekracza budżet, czas, funkcjonalność albo zostaje porzucona. Tanio nie znaczy bezpiecznie. Czasem znaczy dokładnie odwrotnie.

Kto podejmuje decyzje produktowe w projekcie?

To pytanie, które prawie nikt nie zadaje na starcie, a które decyduje o wszystkim.

Są dwa rodzaje wykonawców. Jeden po prostu przepisuje brief na kod. Dostaje twój dokument, robi dokładnie to, co w nim napisano, oddaje i uznaje temat za zamknięty. Kontrakt traktuje jak checklistę do odhaczenia. Discovery, jeśli w ogóle jest, jest etapem sprzedaży, a nie momentem, w którym ktoś kwestionuje twoje założenia.

Drugi rodzaj to partner produktowy. Zanim zacznie planować funkcje i architekturę, pyta, kim są odbiorcy produktu i jaki problem biznesowy to ma rozwiązać. Czasem powie ci, że połowa twojego briefu jest niepotrzebna, a brakuje w nim rzeczy, o której nie pomyślałeś. To bywa irytujące. I zwykle ratuje projekt.

Najgorszy scenariusz nie jest taki, że wykonawca zrobi coś źle. Najgorszy jest taki, że zrobi dokładnie to, o co poprosiłeś, łącznie z błędami, które były w twoim briefie. I dopiero po wdrożeniu okaże się, że zbudowałeś sprawnie działającą aplikacje, której nikt nie potrzebuje.

Czyj jest kod, który powstaje podczas tworzenia aplikacji?

Zaskoczę cię. Domyślnie kod, za który zapłaciłeś, nie jest twój.

W polskim prawie autorskim właścicielem praw do kodu jest twórca, czyli wykonawca, a nie zamawiający. Jeśli nie ma pisemnej umowy przenoszącej majątkowe prawa autorskie, to formalnie ty nie masz prawa samodzielnie modyfikować tego kodu, sprzedać go ani dalej licencjonować. Zapłaciłeś, dostałeś działający system i nadal nie jesteś jego właścicielem w sensie prawnym.

Co gorsza, taka umowa musi być zrobiona porządnie. Artykuł 41 ustawy o prawie autorskim wymaga, żeby umowa wyraźnie wyliczała pola eksploatacji, czyli konkretnie do czego prawa przechodzą. Jeśli tego wyliczenia nie ma, cała umowa przenosząca prawa jest nieważna. Nie „częściowo ważna". Nieważna.

Dlatego zanim podpiszesz cokolwiek, zadaj trzy pytania: czy przenosicie na mnie majątkowe prawa autorskie do kodu, czy umowa wylicza pola eksploatacji, i czy dostaję repozytorium z pełną historią. Jeśli w odpowiedzi słyszysz ogólniki, to jest sygnał ostrzegawczy. Tani freelancer rzadko ma taką umowę gotową. Dobra agencja daje ci to bez pytania.

Po czym poznać wykonawcę, który dowiezie, a nie tylko przepisze twój brief na kod

Analiza wcześniejszych projektów i case studies na stronie wykonawcy jest ważna. Dobre portfolio broni się też dobrymi referencjami. Jednak jest kilka sygnałów, na które warto zwrócić uwagę już przy pierwszej rozmowie z potencjalną firmą tworzącą aplikacje.

Dobrego wykonawcę poznasz po tym, że:

- zadaje niewygodne pytania o twój biznes, zanim policzy cenę,

- pokazuje proces, a nie tylko portfolio, bo proces jest tym, co powtarzalnie dowozi,

- sam z siebie mówi o własności kodu i o tym, co dostaniesz na koniec, zanim ty zapytasz,

- pokazuje, kto konkretnie będzie w zespole i co się stanie, jeśli ktoś odpadnie,

- oferuje wsparcie po wdrożeniu aplikacji

Red flagi są równie czytelne. Jeśli rozmowa kręci się wyłącznie wokół ceny, jeśli nie ma żadnego discovery, jeśli na każdy twój pomysł słyszysz „jasne, zrobimy", to nie jest partner. To wykonawca zlecenia, który przepisze twój brief na kod i zniknie.

Ja to sprawdzam prosto. Dobry wykonawca przynajmniej raz w rozmowie handlowej powie ci „nie" albo „a po co ci to". Ten, który tylko przytakuje, sprzedaje ci swój czas, a nie twój produkt. My w BB8 Studio wolimy powiedzieć klientowi coś niewygodnego na etapie rozmowy niż odkryć to razem z nim trzy miesiące później na produkcji.

4 pytania, które oszczędzą Ci pół roku researchu

Nie musisz od razu wybierać wykonawcy. Zrób jedną rzecz: weź te cztery pytania i zadaj je każdemu, z kim rozmawiasz.

1. Czy przenosicie na mnie majątkowe prawa autorskie do kodu, z wyliczonymi polami eksploatacji?

2. Kto konkretnie będzie w zespole i co się dzieje, jeśli ta osoba odpadnie?

3. Jak wygląda wasz discovery, zanim zaczniecie kodować?

4. Co dokładnie dostaję na koniec, poza działającą aplikacją?

Odpowiedzi rozłożą ci trzy oferty na czynniki pierwsze szybciej niż jakiekolwiek porównanie cen. A jeśli chcesz zobaczyć, jak na te pytania odpowiada agencja, która buduje produkty z AI, to tak pracujemy w BB8.