Jak zlecić stworzenie aplikacji, gdy nie umiesz programować?

Tekst wygenerowany przez AI · Wydawca: Tomasz Niedźwiecki · zawiera oznaczoną reklamę jego usług

Od czego zacząć, gdy nie umiesz programować?

Zacznij od zapisania 6 decyzji, które podejmujesz Ty, a nie wykonawca. Programista dobierze technologię, ale nie wie, kto ma korzystać z produktu, ile możesz wydać ani czy po odbiorze zostaniesz właścicielem kodu.

Sześć decyzji to: zakres pierwszej wersji, odbiorca, model rozliczenia, własność kodu i kont, sposób odbioru oraz utrzymanie. Każdą zamykasz jednym zdaniem, które wklejasz w brief przed rozmową z kimkolwiek.

Poniższa tabela pokazuje, co dokładnie rozstrzygasz i jak może brzmieć zdanie do briefu. Zdania są wzorami formy, więc podstaw własne dane.

Jak opisać zakres i odbiorcę, żeby wyceny dało się porównać?

Zakres opisujesz przez zadania użytkownika, a nie przez listę funkcji. Zdanie „klient wybiera termin i dostaje potwierdzenie” mówi wykonawcy więcej niż hasło „moduł rezerwacji”. Z takiego opisu wycenia dokładnie to samo każdy, kogo zapytasz.

Odbiorcę nazwij konkretną rolą, na przykład „recepcjonistka w gabinecie” albo „kierowca w firmie transportowej”. Jedna rola na pierwszą wersję wystarczy. Druga rola dokłada ekrany, uprawnienia i testy, więc dopisuj ją dopiero po pierwszych użytkownikach.

Jeżeli nie masz pewności, czy pomysł w ogóle nadaje się na produkt, sprawdź to przed zleceniem. Pomoże tekst o tym, kiedy pomysł nie nadaje się na aplikację, bo tanie odrzucenie pomysłu jest lepsze niż drogie zbudowanie.

Jak rozliczać się z wykonawcą, żeby nie płacić za niewiadome?

Najbezpieczniej płacisz za etapy, z odbiorem po każdym. Stała kwota za całość chroni Cię przed rozrostem rachunku, ale tylko wtedy, gdy zakres jest spisany. Godziny pasują do prac, których nie da się z góry opisać, i wymagają raportów, co zostało zrobione.

Do każdego modelu dopisz warunek wyjścia: co dostajesz, jeśli współpraca skończy się po pierwszym etapie. Zapis „kod i projekty ekranów przechodzą na zamawiającego po zapłacie za dany etap” ratuje Cię w sytuacji, w której wykonawca znika w połowie.

Ceny zależą od zakresu i zespołu, więc widełek tu nie podajemy. Rachunki na pięciu przykładach znajdziesz w tekście ile kosztuje stworzenie prostej aplikacji, a rozkład w czasie w tekście o harmonogramie budowy.

Czyje będą kod i konta po odbiorze?

Twoje, ale tylko jeśli umowa to tak mówi. Ustawa o prawie autorskim stanowi: „Umowa o przeniesienie autorskich praw majątkowych wymaga zachowania formy pisemnej pod rygorem nieważności” (art. 53, odczyt 26.10.2026 z tekstu ustawy). Sam mail z ofertą nie przenosi więc praw.

Umowa przenosząca prawa albo licencja obejmuje przy tym wyłącznie pola eksploatacji, które w niej wymieniono (art. 41 ust. 2 tej samej ustawy). Wypisz je z nazwy, na przykład zwielokrotnianie kodu, jego zmiany i rozpowszechnianie, a sprzedaż dostępu klientom wpisz osobno, wprost. Pominięte pole zostaje poza umową.

Druga część to konta. Sklepy z aplikacjami, domena, hosting i baza danych mają być założone na Twoje dane, a wykonawca dostaje dostęp, nie własność. Zmiana wykonawcy za rok nie powinna wymagać proszenia go o zgodę.

Pełną listę punktów umowy opisuje tekst co musi zawierać umowa na stworzenie aplikacji, a o tym, co ma być Twoje, mówi artykuł o prawach autorskich do aplikacji zlecanej.

Jak odebrać pracę, skoro nie czytasz kodu?

Odbierasz zachowanie, a nie kod. Przed zleceniem spisz trzy scenariusze, które muszą przejść od początku do końca, na przykład „klient zakłada konto, składa zamówienie i dostaje potwierdzenie”. Odbiór to Twój test tych scenariuszy na własnym telefonie.

Do odbioru dopisz listę rzeczy, które dostajesz poza samą aplikacją: dostępy, kopię kodu, opis uruchomienia i dane do kont. Bez nich za rok nie odtworzysz, jak to działa.

Na koniec ustal utrzymanie. Aplikacja po wdrożeniu wymaga poprawek błędów, aktualizacji i kopii zapasowych. Zapisz, kto je robi, w jakim czasie reaguje i ile to kosztuje, bo „zajmiemy się tym później” kończy się sporem w najgorszym momencie.

Czy zamiast zlecać, lepiej zbudować samemu w no-code?

Do sprawdzenia wyglądu i pierwszych ekranów tak, do gotowego produktu dla firm zwykle nie. Plan darmowy Lovable daje według cennika 5 kredytów dziennie, do 30 miesięcznie, a Bolt „1M tokens/month”, czyli około miliona tokenów miesięcznie (odczyt obu cenników 26.10.2026).

Taka ilość pozwala zbudować szkic i pokazać go wykonawcy, co samo w sobie skraca brief. Nie rozstrzyga jednak modelu rozliczenia, własności kodu i kont, odbioru ani utrzymania, czyli czterech z sześciu decyzji z tego tekstu.

Rozsądny układ wygląda tak: szkic w narzędziu, potem brief z sześcioma zdaniami, potem wycena od dwóch wykonawców. Szkic jest dla Ciebie i wykonawcy wspólnym językiem, a decyzje z briefu chronią Cię po stronie prawa i pieniędzy.

Źródło: Lovable, cennik, odczyt 26.10.2026; Bolt, cennik, odczyt 26.10.2026.

Od czego zacząć dziś w praktyce?

Zacznij od zapisania sześciu zdań z tabeli własnymi słowami, w jednym dokumencie, w tej kolejności. Jeśli któregoś nie umiesz napisać, to nie wykonawca ma o nim decydować, tylko Ty musisz najpierw to przemyśleć.

Więcej o wyborze sposobu budowy znajdziesz w dziale Budowa. Kiedy brief jest gotowy, poproś o wycenę dwóch lub trzech wykonawców na ten sam dokument i porównaj, jak każdy odpowiada na każdą z decyzji. Wykonawca, który omija pytania o prawa albo utrzymanie, zwykle pokaże ten sam brak po podpisaniu umowy.