Jak czytać ofertę na budowę produktu: poradnik dla założycieli

Oferta na stworzenie produktu zamienia brief w zobowiązania: co powstanie, do kiedy, za ile i co się dzieje, gdy coś się zmienia.

Zasada robocza jest prosta: jeśli jakiś szczegół nie jest zapisany, załóż, że nie jest uwzględniony.

Dobry zakres opisuje, co użytkownik może zrobić, a nie tylko nazwy ekranów. „Użytkownik może założyć konto przez e-mail albo Google i zresetować hasło” da się sprawdzić. „Moduł uwierzytelniania” – nie.

Szukaj osobno wymienionych ról użytkowników, kluczowych ścieżek i narzędzi administracyjnych. Panel administracyjny łatwo pominąć w briefie, a drogo dodać później.

Przejrzysta oferta wymienia, czego nie obejmuje – na przykład copywritingu, tłumaczeń, publikacji w sklepach z aplikacjami, opłat za zewnętrzne subskrypcje czy hostingu po starcie.

Jeśli nie ma sekcji z wyłączeniami, poproś o nią. Wszystko, co wydawało się wliczone, a nie było, wróci później jako zlecenie zmiany.

Nie musisz być inżynierem, ale po lekturze trzeba umieć odpowiedzieć na te pytania:

Na czym produkt zostanie zbudowany – i dlaczego właśnie ta technologia w twoim przypadku?

Kto jest właścicielem kodu i kont: hostingu, domeny, sklepów z aplikacjami, analityki?

Gdzie produkt będzie hostowany i ile mniej więcej będzie to kosztować miesięcznie po starcie?

Czy kod będzie udokumentowany na tyle, żeby mógł go przejąć inny programista?

Dobra agencja wyjaśnia swoje wybory prostym językiem. „Zawsze tego używamy” to nie jest powód.

Jedna data oddania mówi niewiele. Szukaj etapów, przy których za każdym razem jest coś do zobaczenia: zaakceptowane projekty, działająca wersja pod linkiem testowym, wersja gotowa do startu.

Zapytaj, jak często zobaczysz postępy. Cotygodniowe przeglądy to rozsądne minimum; jedno demo na samym końcu to ryzyko.

Sprawdź, czy oferta wspomina o testach, wydajności i dostępności – czy tylko o funkcjach.

Szukaj konkretów: które przeglądarki i urządzenia są obsługiwane, jaką wydajność ma osiągnąć produkt i kto go testuje przed startem.

Upewnij się, co dokładnie obejmuje cena i jak rozłożone są płatności. Zaliczka plus płatności powiązane z etapami to standard; 100% z góry – nie.

Znajdź procedurę zmian. Powinna wyjaśniać, jak nowe zlecenia są wyceniane i akceptowane, zanim ktokolwiek zacznie nad nimi pracować.

Wiele ofert kończy się w dniu startu. Zapytaj, co dalej: czy jest okres gwarancyjny na błędy, jak długo trwa i jak wyceniana jest dalsza praca?

Start bez planu poprawek i aktualizacji to moment, w którym wiele produktów po cichu staje w miejscu.

Co dokładnie jest wyłączone?

Kto będzie na co dzień pracować nad projektem?

Co się stanie, jeśli będziemy musieli zmienić zakres?

Kto na końcu będzie właścicielem kodu i wszystkich kont?

Jakie wsparcie obejmuje okres po starcie?