Brief na aplikację mobilną – jak opisać projekt, żeby dostać porównywalne oferty

Czym jest dobry brief na aplikację mobilną

Brief na aplikację mobilną to dokument, w którym zamawiający zamyka decyzje projektowe wpływające na zakres prac – po to, by dostawca nie musiał przyjmować ich za niego.

O jakości briefu decyduje to, ile pytań zostaje po jego przeczytaniu. Objętość nie jest tu żadną miarą: rozbudowana specyfikacja wymagań bywa świetnym punktem wyjścia, o ile rozstrzyga właściwe rzeczy, a dokument na dwie strony potrafi wystarczyć, jeśli nie zostawia luk.

Po pierwsze, każde milczenie briefu zostaje wypełnione założeniem. Założenie nie znika – zmienia właściciela. Dostawca musi coś przyjąć, żeby w ogóle policzyć godziny. Przyjmuje więc albo wariant tańszy, a wtedy różnica wraca do zamawiającego jako zmiana zakresu w trakcie projektu. Albo przyjmuje wariant ostrożny z buforem – i wtedy zamawiający płaci z góry za niepewność, której sam nie musiał mieć.

Po drugie, brief, który nie rozstrzyga odpowiedzialności, uniemożliwia porównanie ofert. Dwie oferty różniące się o połowę ceny bardzo często nie różnią się ani stawką, ani wydajnością zespołu. Różnią się tym, co każdy z dostawców uznał za swoją stronę granicy.

Po trzecie, najdroższe pozycje wyceny to zwykle te, których w briefie nigdy nie ma. Praca, która nie ma nazwy w języku biznesowym (fundament projektu, biblioteka komponentów, stany błędów, publikacja w sklepach, przeniesienie użytkowników z poprzedniej aplikacji), nie znika przez to, że jej nie opisano.

Dane o projektach informatycznych potwierdzają ten mechanizm. Analiza 5392 projektów IT przeprowadzona przez zespół z Uniwersytetu Oksfordzkiego wykazała, że przekroczenia kosztów nie układają się w rozkład normalny, lecz potęgowy: większość projektów przekracza budżet nieznacznie, ale istnieje gruby ogon realizacji z przekroczeniami skrajnymi (Flyvbjerg i in., 2022). Praktyczny wniosek dla zamawiającego jest niewygodny: ryzyko w projekcie cyfrowym nie jest symetryczne. Odchylenie w dół jest ograniczone, odchylenie w górę – nie. Dlatego domykanie niewiadomych na etapie briefu ma zupełnie inną wartość niż domykanie ich w trakcie.

Podobnie wygląda rozrost zakresu (scope creep). W globalnym badaniu PMI z 2023 roku, na próbie 2588 praktyków i liderów projektowych, rozrost zakresu dotyczył średnio 30% projektów – w czwartej części organizacji o najsłabszych wynikach 37%, a w najskuteczniejszej 23% (PMI, 2024). Rozstrzał między tymi grupami mówi tu więcej niż sama średnia: różnicę robi sposób, w jaki organizacja prowadzi projekty. Zmiana zakresu sama w sobie nie jest niczym złym; w projekcie cyfrowym jest normą. Pytanie brzmi, czy zmiany dotyczą rzeczy, o których obie strony dowiedziały się w trakcie, czy rzeczy, które dało się rozstrzygnąć w pierwszym tygodniu.

Stąd bierze się właściwy status briefu: jest pierwszym dokumentem projektowym. Praktycznie każde pytanie z dobrej checklisty to pytanie, na które i tak trzeba będzie odpowiedzieć. Różnica polega wyłącznie na tym, czy odpowiedź padnie przed wyceną, czy w trzecim miesiącu projektu – kiedy trzeba ją wprowadzić w to, co już powstało.

Co się dzieje z briefem po drugiej stronie

Ścieżka zapytania ofertowego u dostawcy oprogramowania jest w większości firm podobna i warto ją znać, bo tłumaczy, dlaczego dostawca pyta o rzeczy, które z perspektywy biznesu wyglądają na detale.

1. Kwalifikacja wstępna. Czy projekt pasuje do profilu firmy – kompetencje, skala, technologia, termin. Zajmuje kilkanaście minut. Bardzo oszczędny opis rzadko kończy się odmową, częściej rundą pytań: z kilku zdań nie da się jeszcze stwierdzić, czy strony do siebie pasują.
2. Analiza zakresu. Rozłożenie opisu na warstwy: co jest aplikacją mobilną, co warstwą serwerową, co panelem administracyjnym, co projektem graficznym, a co integracją z systemem, którego dostawca jeszcze nie widział. Tu powstaje pierwszy podział pracy i pierwsze widełki.
3. Lista pytań. Wszystko, czego nie da się rozstrzygnąć z briefu, a co zmienia liczbę godzin. Im lepszy brief, tym krótsza lista i tym szybciej wraca wycena.
4. Szczegółowy podział pracy i wycena. Rozbicie zakresu na pozycje na tyle drobne, żeby programista mógł je wycenić bez domysłów – w praktyce od kilkudziesięciu do kilkuset pozycji.
5. Spis założeń. Dokument mówiący, przy jakich warunkach ta cena jest ważna. To on decyduje, co w trakcie projektu jest „w cenie", a co jest zmianą zakresu.

Spis założeń powstaje zawsze. Jeśli brief nie odpowiada na pytanie, odpowiedź i tak zostanie zapisana – tyle że przez dostawcę i na jego warunkach.

Wycena odpowiada na to, co w briefie napisano, i na kilkadziesiąt założeń przyjętych za zamawiającego tam, gdzie brief milczał.

Dwanaście bloków dobrego briefu

Najważniejsza jest tu ostatnia kolumna – pokazuje, co dostawca przyjmie za zamawiającego, jeśli danego bloku zabraknie.

Główne ścieżki użytkownika zamiast listy funkcji

Ścieżka ujawnia to, czego lista haseł nie pokazuje: stany pośrednie, wyjątki i zachowanie aplikacji przy niepowodzeniu. Porównaj „skanowanie paczek" z opisem: kierowca skanuje kod paczki, robi zdjęcie miejsca dostawy, zbiera podpis odbiorcy, zamyka zlecenie; jeśli odbiorcy nie ma, wybiera powód i planuje ponowną próbę. Pierwsze da się wycenić na kilka sposobów, drugie – na jeden.

Metoda działa identycznie w aplikacjach dla klientów, nie tylko dla pracowników. Zamiast „zarządzanie kontem" napisz: użytkownik zmienia dane do faktury, potwierdza je kodem z wiadomości i pobiera korektę; jeśli NIP jest już przypisany do innego konta, widzi komunikat i trafia do formularza zgłoszenia. Zdanie jest dłuższe o kilkanaście słów, a rozstrzyga o kilkunastu godzinach pracy.

Praktyczna wskazówka: przy każdej ścieżce dopisz jedno zdanie o tym, co się dzieje, gdy się nie uda. Brak zasięgu, odrzucona płatność, wygasła sesja, pusta lista, błąd serwera. Obsługa sytuacji, w których coś idzie nie tak, to znaczna część kodu każdej aplikacji – i praktycznie zawsze zerowa część briefu.

Brak czegoś też jest pełnoprawną odpowiedzią. Zdanie „wszyscy użytkownicy mają identyczny dostęp" rozstrzyga blok drugi równie dobrze jak wypisanie pięciu ról.

Wymagania niefunkcjonalne – i jeden punkt, który zmienia najwięcej

Listę z bloku ósmego trzeba przejść świadomie, punkt po punkcie, bo każdy pominięty zostanie rozstrzygnięty za zamawiającego. Decyzja o platformach wiąże się z wyborem między aplikacjami natywnymi a wieloplatformowymi, a obsługa tabletu to osobna praca – dla każdej platformy z osobna.

Osobna kwestia to narzucanie technologii w briefie. Zasada jest prosta: narzucaj, gdy masz twardy powód – i ten powód napisz. Twardym powodem jest istniejący zespół, który przejmie kod po wdrożeniu, wymóg użycia sprzętu lub zestawu narzędzi programistycznych (SDK), które są dostępne wyłącznie natywnie, albo standard bezpieczeństwa obowiązujący w organizacji. Podany powód pozwala dostawcy zaproponować tańszą drogę do tego samego celu. Narzucenie technologii bez uzasadnienia zawęża pole ofert i bywa droższe. Tworzy też niezręczną sytuację: trudno wymagać odpowiedzialności za rezultat od kogoś, komu odebrano wybór narzędzia.

Jeden punkt tej listy potrafi zmienić wycenę o kilkadziesiąt procent, a w briefach pojawia się najrzadziej ze wszystkich: praca bez zasięgu. Różnica między „aplikacja pokazuje komunikat o braku sieci" a „aplikacja działa w pełni bez połączenia i synchronizuje dane po jego powrocie" to różnica między jedną pozycją a osobnym modułem. Składają się na niego: lokalna baza danych, kolejkowanie operacji, rozstrzyganie konfliktów i migracje struktury danych przy każdej aktualizacji, która tę strukturę zmienia. To jedno z najdroższych pojedynczych wymagań, jakie mogą pojawić się w briefie – i jednocześnie najrzadziej opisywane precyzyjnie.

Jeśli użytkownicy pracują w miejscach bez zasięgu – magazyn, podziemia, teren, hala, samolot – napisz to wprost i opisz, co dokładnie ma działać bez połączenia, a co może go wymagać.

Ten punkt bywa jednak nadużywany: praca bez zasięgu zmienia najwięcej wtedy, gdy w ogóle jest potrzebna. Jeśli twoi użytkownicy zawsze mają połączenie, największym pojedynczym czynnikiem wyceny będzie zwykle liczba ról oraz liczba i stan integracji.

Sposób zarabiania: reguły sklepów bywają ważniejsze niż pomysł

Modele sprzedaży w aplikacji podlegają regulaminom Apple i Google, a te potrafią zmienić sposób realizacji wymagania albo uczynić je niewykonalnym w formie opisanej w briefie. Wytyczne App Store wprost zabraniają odblokowywania treści i funkcji własnymi mechanizmami: wymieniają klucze licencyjne, kody QR i znaczniki rzeczywistości rozszerzonej (Apple, 2026). Kody rabatowe na treści cyfrowe kupowane w aplikacji trzeba więc domyślnie realizować mechanizmami sklepów, a nie własnym systemem kodów. Od tej zasady istnieją dziś wyjątki dotyczące sprzedaży poza aplikacją, ale są obwarowane warunkami i zmieniają się – tym bardziej warto rozstrzygnąć model sprzedaży już na etapie briefu.

Konsekwencja praktyczna: słowo „subskrypcja" w briefie zostanie wycenione jako jedna pozycja, a w rzeczywistości jest modułem obejmującym stany cyklu życia subskrypcji, przywracanie zakupów, weryfikację po stronie serwera oraz uzgadnianie uprawnień między kanałami sprzedaży. Doświadczenie Norbsoft z ekosystemami płatności – od bramek płatniczych po płatności zbliżeniowe – pokazuje, że to zwykle jedna z najbardziej niedoszacowanych pozycji w całej wycenie.

Budżet: podanie kwoty działa na twoją korzyść

Budżet bywa pomijany częściej niż którykolwiek inny blok, a obawa, która za tym stoi, jest zawsze ta sama: „jeśli podam kwotę, dostawca dopasuje do niej cenę". Ta obawa zasługuje na poważne potraktowanie, a potem na zestawienie z tym, co dzieje się w rzeczywistości.

W praktyce wyceny wychodzą wyżej niż kwota, którą zamawiający miał w głowie, i to znacznie częściej niż odwrotnie. Odpowiada za to zakres, który wychodzi na jaw dopiero przy liczeniu godzin: fundament projektu, biblioteka komponentów, stany błędów, testy i publikacja istnieją w każdej aplikacji, a w wyobrażeniu o cenie – rzadko. Rozmowa dotyczy więc zwykle tego, jak zmieścić zakres w budżecie. Podanie widełek rzadko podbija ofertę, a ich brak niemal zawsze kosztuje obie strony kilka tygodni.

Co się dzieje, gdy budżet jest znany: dostawca może zaproponować wariant, który się w nim mieści – węższą pierwszą wersję, etapowanie, rezygnację z funkcji, która pochłania nieproporcjonalnie dużo pracy. Bez tej informacji ma do wyboru dwie złe drogi: wyceni pełny zakres z briefu i dostaniesz ofertę, której nie kupisz, albo zawęzi go po swojemu – a wtedy jego propozycji nie da się porównać z ofertą konkurenta, który zawęził inaczej.

Jeśli mimo wszystko nie chcesz podawać kwoty, wystarczy jej odpowiednik: przedział, rząd wielkości albo górna granica, powyżej której projekt przestaje mieć sens biznesowy. Każde z tych zdań niesie tę samą informację i pozwala dopasować propozycję. Jedno zastrzeżenie dla uczciwości: budżet nie zastępuje opisu zakresu. Sama kwota bez zakresu jest dla wyceniającego równie mało użyteczna jak sam zakres bez kwoty.

Podział odpowiedzialności – sekcja, której najczęściej brakuje

Podział odpowiedzialności to wskazanie, która strona dostarcza każdy element projektu – i to on decyduje o porównywalności ofert.

Punkt wyjścia jest prosty: projekt nazywany „aplikacją mobilną" obejmuje znacznie więcej niż aplikację. Warstwa serwerowa, projekt graficzny, treści, integracje i utrzymanie potrafią razem pochłonąć większą część budżetu niż sam kod na urządzeniu. Brief, który opisuje wyłącznie ekrany, nie mówi nic o tej części.

Obszary, dla których brief powinien wskazać właściciela:

1. Warstwa serwerowa i API – czy istnieje, kto ją rozwija, kto odpowiada za dodanie nowych funkcji w API, jeśli okażą się potrzebne w trakcie.
2. Projekt graficzny, czyli projektowanie interfejsu i doświadczeń użytkownika (UX/UI) – kto projektuje ekrany, czy istnieje design system lub księga identyfikacji wizualnej.
3. Treści – teksty, zdjęcia, tłumaczenia oraz opisy i zrzuty ekranu do sklepów (to praca marketingowa, nie programistyczna, i ktoś musi ją mieć przypisaną). Tu należą też polityka prywatności i regulamin aplikacji: oba sklepy wymagają odsyłacza do polityki przy każdej publikacji, więc jej brak zatrzymuje wydanie niezależnie od gotowości kodu. Zamawiający zwykle zakłada, że to część „publikacji w sklepach", a dostawca – że to treść po stronie zamawiającego, bo wymaga decyzji prawnych, których nie podejmie za klienta. Klasyczne milczenie briefu kończące się poślizgiem na finiszu.
4. Integracje z systemami wewnętrznymi – kto konfiguruje dostępy, środowiska testowe i przykładowe dane.
5. Konta w sklepach i publikacja – kto jest właścicielem kont Apple Developer i Google Play, kto publikuje, na czyim koncie stoi aplikacja.
6. Utrzymanie po wdrożeniu – kto reaguje na zgłoszenia, kto aktualizuje aplikację przy zmianach systemów, kto odpowiada za zgodność z nowymi wymogami sklepów. Osobno rozstrzygnij, co obejmuje gwarancja (bezpłatne usuwanie wad po odbiorze – i przez ile miesięcy), a co płatne utrzymanie; roczna gwarancja i miesięczna różnią się o koszt, którego nie widać w cenie wdrożenia.
7. Kod, repozytorium i prawa do niego – czyj jest kod, gdzie stoi repozytorium i od kiedy masz do niego dostęp. Przeniesienie autorskich praw majątkowych bywa osobną pozycją cenową, a oferta „na licencji" daje ci znacznie mniej; w prawie polskim takie przeniesienie wymaga zresztą formy pisemnej. Jeśli aplikacja ma być odsprzedawana albo wdrażana u twoich klientów, zastrzeż w briefie dopuszczalne licencje bibliotek zewnętrznych.
8. Dane osobowe w trakcie projektu – czy dostawca w ogóle otrzymuje dostęp do danych produkcyjnych, czy potrzebna jest umowa powierzenia przetwarzania i czy dopuszczasz podpowierzenie oraz przetwarzanie poza wskazanym krajem.
9. Koszty usług zewnętrznych – kto zakłada i opłaca usługi zewnętrzne: konta deweloperskie, mapy, wysyłkę wiadomości, powiadomienia, hosting, certyfikaty i narzędzia analityczne. Ten wydatek wraca co miesiąc, a jedna oferta może go zawierać, druga nie, przez co przestają być porównywalne.

W praktyce układy sprowadzają się do trzech modeli. Warto nazwać swój w pierwszym akapicie briefu.

Model B obejmuje też dwa układy o własnej mechanice. Pierwszy to kilku dostawców naraz – agencja od projektu graficznego, dostawca oprogramowania od aplikacji, wewnętrzny zespół od warstwy serwerowej. Brief musi wtedy wskazać, kto koordynuje styki między nimi, bo to osobna praca i osobna odpowiedzialność. Drugi to przejęcie niedokończonego kodu po poprzednim wykonawcy. Tu wycena z opisu funkcji jest z zasady niemożliwa: rozsądnie jest zacząć od audytu kodu, a dopiero jego wynik pozwala policzyć resztę.

Cztery zdania, które warto wkleić do briefu dosłownie:

• „Zakres tego zapytania obejmuje …, nie obejmuje …"
• „API [istnieje i jest udokumentowane / powstaje równolegle / oczekujemy, że dostarczy je wykonawca]."
• „Projekt graficzny [dostarczymy / zamawiamy u wykonawcy]."
• „Aplikacja [nie musi / musi] działać bez dostępu do sieci; jeśli musi – bez połączenia mają działać: …"

Jeśli nie wiesz, którego modelu potrzebujesz, napisz właśnie to. Zdanie „nie mamy jeszcze rozstrzygnięcia, czy warstwę serwerową robimy wewnętrznie; prosimy o wycenę w obu wariantach" jest znacznie lepszym briefem niż milczenie na ten temat. Model współpracy jest zresztą kwestią osobną od modelu rozliczeń – obie decyzje warto podjąć świadomie.

Projekt prowadzony w układzie zbliżonym do modelu C: zakres prac objął aplikację na tablety i warstwę serwerową (MPWiK Wrocław).

Ostrzeżenie praktyczne przy porównywaniu ofert: czytaj najpierw sekcję założeń, dopiero potem cenę. Jeśli jedna oferta zakłada dostarczony projekt graficzny i gotowe API, a druga wlicza jedno i drugie, to nie są oferty na ten sam projekt.

Co dostarcza zamawiający oprócz pieniędzy

Rozdzielenie pracy między firmy pomija zasób, który w harmonogramie waży najwięcej i najczęściej bywa niedoszacowany: czas ludzi po stronie zamawiającego. W projekcie aplikacji twoi ludzie mają realny udział, więc ich czas trzeba zaplanować tak samo jak pracę dostawcy.

Brief powinien rozstrzygnąć przynajmniej cztery takie sprawy:

• Kto testuje wydania i na czym. Czy istnieje zestaw urządzeń do testów po twojej stronie, czy trzeba go zapewnić. Ile trwa jedna runda odbioru i kto zbiera uwagi, jeśli zgłasza je kilka działów naraz.
• Kto rozstrzyga, czy zgłoszenie to błąd, czy zmiana zakresu. To najczęstszy spór przy odbiorze – zasadę trzeba ustalić, zanim się pojawi.
• W jakim rytmie zapadają decyzje. Projekt, w którym decyzja zajmuje dwa tygodnie, trwa dłużej niż identyczny projekt z decyzją w dwa dni – tę różnicę widać wprost w harmonogramie.
• Kto przygotuje dane i dostępy. Zanonimizowany zbiór testowy, konta w systemach źródłowych, środowisko z realnymi danymi. To praca, o której nikt nie pamięta na etapie wyceny, a która regularnie opóźnia start o tydzień lub dwa.

Rozstrzygnięcie ich w briefie ma jeszcze jedną zaletę: pozwala porównać harmonogramy w ofertach. Dostawca, który zna twoją dostępność, może zaplanować pracę realistycznie zamiast zakładać, że odpowiedzi przychodzą tego samego dnia.

Stan zastany: czy zastępujesz coś, co już działa

Ten wątek jest jednocześnie bardzo kosztowny i prawie nieobecny w briefach. Poprzednia aplikacja bywa wspominana mimochodem, jako tło historyczne – a zmienia zakres projektu na tyle, że nie da się jej dopisać jako kilku dodatkowych ekranów.

Zastąpienie działającej aplikacji, z której korzystają realni użytkownicy, to osobny blok pracy – objętością porównywalny z modułem funkcjonalnym. Co brief powinien powiedzieć:

• Czy nowa aplikacja ma zastąpić istniejący wpis w sklepach, czy być publikowana jako nowa pozycja. Aktualizacja zachowuje oceny, recenzje i dotychczasowe instalacje. Nowa pozycja zaczyna od zera.
• Kto ma dostęp do kont deweloperskich i – w przypadku Androida – do klucza podpisu aplikacji. To trzeba sprawdzić jako pierwsze, przed jakąkolwiek wyceną.
• Czy są aktywne subskrypcje lub zakupy do przeniesienia. Subskrypcji odnawialnych nie da się przenieść do nowego wpisu w sklepie; jedyną drogą jest przekazanie całej aplikacji między kontami. To mocny argument za wariantem „aktualizacja".
• Co dzieje się z danymi zapisanymi lokalnie w starej aplikacji.
• Czy przewidziany jest okres równoległego działania obu aplikacji, czy przełączenie jednorazowe.
• Czy istnieje analityka poprzedniej wersji. To darmowa wiedza o tym, z czego użytkownicy naprawdę korzystają – warta więcej niż większość warsztatów.

Sprawdź, zanim wyślesz zapytanie. Jeśli zastępujesz istniejącą aplikację na Androida, ustal, gdzie jest klucz podpisu. Aktualizacja wpisu w sklepie jest weryfikowana względem oryginalnego certyfikatu – bez niego pozostaje publikacja pod nową nazwą pakietu, czyli start od zera. Uwaga porządkująca: „klucz został u poprzedniego dostawcy" to nie to samo co „klucz utracony", więc najpierw po prostu spróbuj go odzyskać. Jeśli aplikacja korzysta z podpisywania po stronie sklepu (Play App Signing), sytuacja jest znacznie prostsza, bo zresetować trzeba wyłącznie klucz przesyłania (Google, 2026). Realne ryzyko dotyczy więc głównie wpisów utworzonych przed wprowadzeniem obowiązkowego formatu Android App Bundle w 2021 roku.

Wymiana istniejącego rozwiązania na własne bywa też świadomą decyzją strategiczną. Aplikacja PANEK CarSharing powstawała w kontekście przejścia z rozwiązania licencjonowanego od zewnętrznego dostawcy na system własny – a to zupełnie inny projekt niż budowa od zera, także po stronie briefu. Jeśli punktem wyjścia jest istniejąca aplikacja, której stanu nie znasz, osobnym, tańszym krokiem bywa audyt i modernizacja zamiast pełnej wymiany.

Wszystkie te kłopoty ktoś odziedziczył po poprzednim wykonawcy – a za trzy lata to twój projekt będzie dla kogoś „stanem zastanym". Napisz brief tak, żeby nie stać się tą historią:

• konta Apple Developer i Google Play zakładane od pierwszego dnia na twoją firmę, a nie na wykonawcę;
• repozytorium po twojej stronie od pierwszego dnia pracy;
• usługi zewnętrzne (analityka, powiadomienia, bramka płatnicza) zarejestrowane na twoje dane;
• dokumentacja jako element odbioru, wpisany do umowy.

Na starcie żaden z tych punktów nie kosztuje prawie nic – przy zmianie dostawcy każdy potrafi kosztować bardzo dużo.

Siedem rzeczy, których prawie nigdy nie ma w briefie

Ta praca istnieje w każdym projekcie niezależnie od tego, czy ktoś ją opisał, i nie jest przedmiotem pretensji do zamawiających. Brief nie musi jej rozpisywać w szczegółach.

1. Fundament projektu. Zanim powstanie pierwszy ekran, ktoś musi zbudować szkielet aplikacji: strukturę projektu, konfigurację środowisk (deweloperskie, testowe, produkcyjne), warstwę komunikacji z serwerem, obsługę błędów, bezpieczne przechowywanie danych logowania. W briefach tego nie ma, bo nie widać tego na żadnym ekranie – a zrobić to trzeba w każdym projekcie.
2. Biblioteka komponentów. Przyciski, pola formularzy z pełnym zestawem stanów, listy, karty, okna, komunikaty, ekrany pustych list, ładowania i błędu. Projekt graficzny je rysuje, ale ktoś musi je jeszcze zakodować, zanim jakikolwiek moduł funkcjonalny z nich skorzysta. To realnie jedna z największych pozycji w każdej wycenie i pierwsza, która znika, gdy wycenę robi się pobieżnie.
3. Stany, w których coś idzie nie tak. Brak sieci, pusta lista, błąd serwera, wygasła sesja, odmowa uprawnienia, plik, który się nie pobrał.
4. Publikacja w sklepach. Konta deweloperskie, certyfikaty i klucze podpisu, opisy i zrzuty ekranu w wymaganych rozmiarach, konto testowe dla recenzenta, obsługa odrzucenia i poprawki. Do tego obowiązkowe i osobne dla obu sklepów deklaracje o przetwarzaniu danych: Apple wymaga ich przy każdym przesłaniu nowej aplikacji i każdej aktualizacji (Apple, 2026), Google prowadzi analogiczną sekcję „Bezpieczeństwo danych" (Google, 2026). Obie wymagają inwentaryzacji tego, co aplikacja i jej biblioteki zewnętrzne zbierają – a tego nikt nie robi „przy okazji".
5. Testy. Zarówno automatyczne, pisane przez programistów i będące częścią kosztu wytworzenia, jak i manualne, wymagające osobnej roli. Brief zwykle o nich milczy, a potem pojawia się pytanie, dlaczego oferta zawiera pozycję „testy".
6. Rzeczy potrzebne nawet w projekcie jednojęzycznym. Wyprowadzenie tekstów poza kod, formatowanie dat i liczb, obsługa stref czasowych. Robi się to niezależnie od liczby języków, bo dopisanie tego później kosztuje wielokrotnie więcej.
7. Powiadomienia push – pełny moduł. Rejestracja urządzenia, powiązanie z użytkownikiem, wyrejestrowanie przy wylogowaniu (bez tego kolejna osoba logująca się na tym samym urządzeniu dostaje cudze powiadomienia), obsługa odmowy zgody, otwarcie właściwego ekranu po kliknięciu, centrum powiadomień w aplikacji. Plus pytanie, na które brief musi odpowiedzieć: kto i z jakiego narzędzia będzie te powiadomienia wysyłał.

Przy planowaniu terminów trzeba uwzględnić jeszcze jedną właściwość wydań mobilnych. Wadliwe wydanie da się zatrzymać – Google Play pozwala wstrzymać nawet wersję udostępnioną wszystkim użytkownikom, a jej miejsce automatycznie zajmuje poprzednia wersja dla nowych instalacji (Google, 2026). Nie da się natomiast odebrać wadliwej wersji tym, którzy zdążyli już zaktualizować aplikację. Dla nich naprawą jest wyłącznie nowe wydanie, które ponownie przechodzi weryfikację w sklepie, i właśnie ten czas trzeba uwzględnić w harmonogramie.

Ostatnia pozycja wraca do pierwszego bloku briefu: cel ma być mierzalny, ale nigdzie potem nie pada pytanie, czym go zmierzysz. Zdarzenia analityczne, definicja lejka konwersji i pulpit (dashboard) z wynikami to praca, której nie widać na żadnym ekranie, dokładnie jak fundament projektu. Brief, który stawia cel i nie zamawia pomiaru, gwarantuje, że po roku nikt nie odpowie na pytanie, czy inwestycja się opłaciła.

Nie trzeba opisywać tego wszystkiego w briefie. Trzeba tylko nie zakładać, że skoro czegoś nie ma na liście funkcji, to nie ma tego w projekcie – i przy porównywaniu ofert sprawdzić, czy dostawcy to uwzględnili. Jeśli w ofercie nie widać tych pozycji, dostawca ich nie policzył; zapytaj wprost, gdzie w wycenie siedzą.

Brief zależy od typu aplikacji

Najlepiej sprawdza się podział według tego, jak aplikacja ma się do danych i do sieci. Cztery typy poniżej wyznaczają punkty na tej osi; klasyfikacja nie jest zamknięta – jeśli twoja aplikacja łączy dwa z nich, po prostu odpowiedz na pytania z obu. Każdy typ generuje inny zestaw pytań i inne ryzyko.

Typ 1 – aplikacja transakcyjna online

Aplikacja transakcyjna to interfejs do katalogu i koszyka: dane są po stronie serwera, a urządzenie niemal zawsze ma połączenie. Dotyczy to handlu elektronicznego, rezerwacji i zamawiania.

Pytania, na które brief powinien odpowiedzieć:

• Skąd pochodzą dane o produktach i cenach – z jednego systemu czy z kilku – i jak często się zmieniają?
• Czy ceny i dostępność są indywidualne dla użytkownika (rabaty, umowy, ceny B2B)?
• Jakie metody płatności trzeba obsłużyć i czy płatność kończy się w aplikacji, czy przekierowaniem?
• Czy konta są wspólne z serwisem internetowym, czy zakładane osobno w aplikacji?
• Ile produktów liczy katalog i czy istnieje już wyszukiwarka po stronie serwera?
• Co dzieje się po złożeniu zamówienia: śledzenie statusu, faktury, zwroty, reklamacje?
• Jeśli sprzedajesz czas lub zasób, a nie towar (wizyty, sale, sprzęt, kursy): skąd bierze się dostępność, kto i do kiedy może odwołać albo przesunąć rezerwację i czy kalendarz jest prowadzony w systemie centralnym?

Typowa pułapka: „koszyk jak na stronie". Koszyk uzgadniany między aplikacją a serwisem internetowym – ta sama zawartość w obu miejscach, przed zalogowaniem i po nim – to osobne, nietrywialne zagadnienie. W briefie zajmuje jedno słowo, w projekcie jest modułem obejmującym scalanie sesji anonimowej z kontem, rozstrzyganie rozbieżności i utrzymanie spójności cen.

Aplikacja transakcyjna: katalog po stronie serwera, lista produktów z filtrami i sortowaniem oraz personalizacja treści od pierwszego uruchomienia (MODIVO).

Typ 2 – aplikacja, w której dane powstają na urządzeniu

Dane powstają tu na urządzeniu użytkownika – zwykle poza biurem – i muszą trafić do systemu centralnego. Praca bez zasięgu jest w takiej aplikacji częstym, ale nie zawsze koniecznym wymaganiem: o przynależności do tego typu decyduje kierunek przepływu danych.

Pytania, na które brief powinien odpowiedzieć:

• Które operacje muszą działać bez zasięgu, a które mogą wymagać połączenia?
• Jak długo urządzenie może pozostawać bez połączenia – godziny, dni, tygodnie?
• Ile danych musi być dostępnych lokalnie: cały katalog czy tylko przypisane zlecenia?
• Co się dzieje, gdy dwie osoby zmodyfikowały ten sam rekord bez połączenia – kto wygrywa i kto o tym decyduje?
• Czy dane na urządzeniu są wrażliwe (dane osobowe, cenniki, dokumentacja techniczna) i jakiego poziomu zabezpieczenia wymagają?
• Czy dane wprowadzone bez połączenia mają termin ważności lub wymóg audytu?

Typowa pułapka: „praca w terenie" nie znaczy „bez zasięgu". Serwisant w mieście ma zasięg. Jeśli tryb bez połączenia jest naprawdę potrzebny, trzeba go opisać precyzyjnie; jeśli nie jest – warto napisać wprost, że aplikacja może wymagać połączenia. Każde z tych zdań oszczędza pieniądze: jedno domyka wymaganie, drugie je zdejmuje.

Osobna uwaga, o której łatwo zapomnieć: lokalna baza danych oznacza także migracje jej struktury przy każdej aktualizacji, która tę strukturę zmienia. Pominięcie tego to jedna z niewielu rzeczy w projekcie mobilnym, która potrafi bezpowrotnie zniszczyć dane użytkownika.

Narzędzie dla handlowców w terenie: praca bez połączenia, role i uprawnienia, konfigurator produktu i moduł zamówień – aplikacja na iPada (SITS).

Jeśli budujesz narzędzie dla pracowników terenowych, rozwinięcie tego wątku – wraz z konsekwencjami dla integracji i procesów – znajdziesz we wpisie o aplikacjach mobilnych dla biznesu B2B.

Typ 3 – aplikacja treściowa i medialna

W aplikacji treściowej wartością jest sama zawartość i dostęp do niej; rozstrzygające jest to, skąd się bierze, kto ją redaguje po wdrożeniu i jak trafia na urządzenie. Sprzedaż treści i ochrona przed kopiowaniem to częsty wariant – mieszczą się tu jednak równie dobrze wydawnictwa i kursy, jak wewnętrzna baza wiedzy czy materiały szkoleniowe.

Pytania, na które brief powinien odpowiedzieć:

• Skąd pochodzi treść – z systemu zarządzania treścią (CMS), z plików, z transmisji na żywo?
• Kto redaguje i publikuje treść po wdrożeniu, w jakim narzędziu i jak często?
• W jakim formacie: tekst, dokumenty o stałym układzie (PDF, publikacja elektroniczna w formacie ePub), obraz, wideo, audio?
• Czy treść ma być dostępna bez połączenia i czy w związku z tym wymaga ochrony przed skopiowaniem?
• Jaki jest model płatności: pojedynczy zakup, subskrypcja, częściowy dostęp, dostęp powiązany z prenumeratą papierową lub kontem na stronie?
• Czy w aplikacji będą reklamy – własne czy z zewnętrznego systemu – i w jakich formatach?
• Czy jest wyszukiwarka po treści i czy obejmuje archiwum?

Typowa pułapka: uzgadnianie uprawnień między kanałami. Użytkownik, który wykupił subskrypcję na stronie internetowej, oczekuje dostępu w aplikacji – i odwrotnie. Wymaga to jednego modelu uprawnień po stronie serwera, obsługi zakupów dokonanych w sklepach z aplikacjami i pogodzenia obu źródeł. Na tę pracę trzeba zaplanować osobną pozycję w wycenie.

Aplikacja treściowa: materiały z własnego systemu zarządzania treścią, dostęp bez połączenia i architektura modułowa dla wielu rynków (MAN Service).

Typ 4 – aplikacja towarzysząca urządzeniu lub procesowi fizycznemu

Aplikacja tego typu rozmawia ze światem fizycznym – przez Bluetooth, komunikację bliskiego zasięgu (NFC), skanowanie kodów lub lokalizację – i niesie wyższe ryzyko techniczne niż pozostałe.

Pytania, na które brief powinien odpowiedzieć:

• Z jakim urządzeniem lub sprzętem aplikacja się łączy, jakim protokołem i czy istnieje dokumentacja?
• Czy urządzenie jest gotowe i dostępne do testów, czy powstaje równolegle?
• Czy komunikacja odbywa się bezpośrednio z urządzeniem, czy przez serwer?
• Co dokładnie oznacza „skanowanie": jakie kody, co dzieje się po zeskanowaniu, ile skanów z rzędu?
• Czy lokalizacja jest potrzebna w tle, czy wyłącznie przy aktywnej aplikacji?
• Ile modeli urządzeń trzeba obsłużyć i czy różnią się protokołem?

Pytanie o lokalizację w tle nie jest techniczną ciekawostką. Google Play traktuje dostęp do lokalizacji w tle jako uprawnienie szczególnie wrażliwe, wymagające osobnego uzasadnienia i przeglądu przed publikacją (Google, 2026). Ta decyzja wpływa na wymogi sklepów i na zużycie baterii, nie tylko na kod.

Typowa pułapka: dokumentacja producenta urządzenia bywa niekompletna albo nieaktualna, a rozbieżność wychodzi dopiero przy pierwszym połączeniu. Warto napisać w briefie, czy urządzenie można udostępnić na czas wyceny – to znacząco zawęża widełki. Doświadczenie w komunikacji z urządzeniami zewnętrznymi jest tu ważniejsze niż w pozostałych typach właśnie dlatego, że część ryzyka leży poza kodem aplikacji.

Aplikacja sterująca procesem fizycznym: lokalizacja pojazdów, rezerwacja i wynajem, do tego rozliczenie i subskrypcja (PANEK CarSharing).

Część projektów nie mieści się w żadnym z tych czterech typów.

Aplikacja samoobsługowa klienta – konto, umowy, faktury, zgłoszenia, historia usług – jest jednym z najczęstszych przypadków w telekomunikacji, ubezpieczeniach, energetyce i finansach, a nie jest ani katalogiem z koszykiem, ani narzędziem terenowym. Rozstrzygające jest w niej to, ile systemów źródłowych trzeba pogodzić w jednym widoku i które operacje klient może wykonać sam, a które kończą się zgłoszeniem do obsługi.

Aplikacja z treściami tworzonymi przez użytkowników (komentarze, oceny, profile, czat, zdjęcia) dokłada wymóg, o którym briefy milczą niemal zawsze: sklepy oczekują mechanizmów moderacji, zgłaszania nadużyć i blokowania użytkowników. To osobny moduł i osobny proces operacyjny po stronie zamawiającego.

Aplikacja wewnętrzna dla pracowników wymaga logowania jednokrotnego (SSO: jedno logowanie do wszystkich systemów firmy) i przemyślenia dystrybucji. Na Androidzie jest to stosunkowo proste, na iOS – mocno reglamentowane i wymagające osobnego programu Apple; obu platform nie należy tu traktować jako równoważnych. Dochodzi też pytanie o szkolenie użytkowników, flotę urządzeń i pierwszą linię wsparcia po premierze.

Aplikacja lojalnościowa i marketingowa obejmuje dodatkowo kartę w portfelu w telefonie (Apple Wallet, Google Wallet), kupony, powiadomienia oparte na lokalizacji i integrację z systemem zarządzania relacjami z klientami (CRM).

Aplikacja w obszarze regulowanym – finanse, zdrowie – bywa przypadkiem, w którym koszt zgodności przewyższa koszt samych funkcji; brief powinien wymienić obowiązujące regulacje i wskazać, kto po stronie zamawiającego je interpretuje.

Aplikacja samoobsługowa: wgląd w przebieg usługi, dokumenty i komunikacja – w osobnych wariantach dla dwóch grup użytkowników (Promedica24).

Pięć antywzorców briefu

1. „Aplikacja jak [znana marka], ale prostsza"

Nie wiadomo, które elementy tamtej aplikacji są istotą, a które tłem. Aplikacje dużych marek są efektem lat pracy i zawierają mnóstwo rzeczy, których nie widać. „Prostsza" nie mówi nic o zakresie.

Jak lepiej: wskaż referencję i wypisz trzy rzeczy, które mają działać tak samo, oraz trzy, których nie potrzebujesz.

2. Lista funkcji bez kontekstu użycia

Dostawca wycenia wtedy hasła, a każde z nich da się rozumieć na kilka sposobów. „Powiadomienia" mogą znaczyć jedno pole w ustawieniach albo moduł z podziałem odbiorców i harmonogramem wysyłek.

Jak lepiej: przy każdej funkcji jedno zdanie o tym, kto i kiedy z niej korzysta.

3. Nazwanie standardu zamiast opisania wymagania

Skrótowe powołanie się na standard – „zgodność z RODO", „dostępność na podstawowym poziomie", „bezpieczeństwo bankowe" – tworzy zobowiązanie o zakresie, którego żadna ze stron nie ustaliła. Albo podnosi cenę, albo staje się źródłem sporu przy odbiorze.

Jak lepiej: napisz, co konkretnie ma działać, i wskaż, kto po twojej stronie odpowiada za interpretację przepisów.

Po pierwsze, „poziom podstawowy" nie jest nazwą poziomu zgodności z wytycznymi dostępności: poziomy to A, AA i AAA (W3C, 2018). Trybu ciemnego też nie należy zaliczać do wymagań dostępności, choć bywa za takie brany. Po drugie, w przypadku dostępności odłożenie tematu „na drugą wersję" nie zawsze jest decyzją zakresową. Europejski akt o dostępności obowiązuje od 28 czerwca 2025 r. (Komisja Europejska, 2025), a w Polsce wdraża go ustawa z 26 kwietnia 2024 r. (Dz.U. 2024 poz. 731). Jeśli aplikacja mieści się w zakresie tych przepisów – bankowość i płatności, handel elektroniczny, transport pasażerski, książki elektroniczne, usługi telekomunikacyjne – dostępność jest wymogiem prawnym i nie podlega negocjacji zakresu. Co to oznacza w praktyce dla aplikacji mobilnej, omawiamy szczegółowo we wpisie o dostępności aplikacji mobilnej po EAA.

4. „Szczegóły ustalimy na etapie analizy"

W połączeniu z oczekiwaniem ceny ryczałtowej to sprzeczność, którą dostawca rozwiązuje jedynym dostępnym sposobem: buforem w cenie albo bardzo wąsko zdefiniowanym zakresem.

Jak lepiej: rozstrzygnij kluczowe kwestie przed zapytaniem albo świadomie kup etap analizy jako osobną, krótką pracę i dopiero potem zbieraj oferty na realizację. Drugie rozwiązanie jest często tańsze niż bufor – u nas odpowiada mu Badanie Potrzeb, zamykane specyfikacją i oszacowaniem pracochłonności, a w szerszym ujęciu Prognoza Wartości.

5. Brief opisujący system, a zamawiający aplikację

Opis obejmuje panel administracyjny, warstwę serwerową, integracje i raportowanie, a zapytanie dotyczy aplikacji mobilnej. Oferty stają się nieporównywalne, bo każdy dostawca inaczej poprowadzi granicę.

Jak lepiej: jeden akapit „co jest w zakresie tego zapytania, a co jest poza nim".

Jak brief przekłada się na cenę i termin

Wycena projektu mobilnego prawie zawsze jest przedziałem. Dolna granica to scenariusz, w którym wszystkie założenia się potwierdzają: API działa i jest udokumentowane, projekt graficzny jest kompletny, rola jest jedna, praca bez zasięgu nie jest wymagana, treści są gotowe. Górna to scenariusz, w którym niewiadome okazują się dodatkową pracą.

Szerokość tego przedziału jest wprost proporcjonalna do liczby pytań, na które brief nie odpowiada. W umowie przedział musi się jednak zamienić w jedną liczbę – i zamienia się na jeden z trzech sposobów:

• bliżej górnej granicy, jeśli cena jest stała, a zakres niepewny – płacisz wtedy za niepewność, której mogłeś nie mieć;
• bliżej dolnej, jeśli zakres zdefiniowano wąsko – i wtedy różnica wraca jako zmiany zakresu w trakcie;
• rozliczeniem za faktyczny czas pracy, jeśli obie strony akceptują niepewność wprost.

Ta sama logika rządzi karami umownymi, o które zamawiający często upominają się odruchowo. Kara wchodzi w cenę jako bufor ryzyka – dokładnie tak samo jak niedopowiedziany zakres. Żądanie wysokich kar bez konkretnego powodu podnosi cenę oferty, zamiast zabezpieczać projekt. Zastrzegaj je tam, gdzie masz twardy termin – kampanię, wymóg prawny – i ten powód napisz.

Dobór modelu rozliczeń wynika więc z jakości briefu. Cena stała ma sens przy dobrze określonych wymaganiach; rozliczenie za czas pracy – przy dużej dynamice i wymaganiach, które dopiero się układają. Najmocniej zawężają widełki – w tej kolejności:

1. Rozstrzygnięcie podziału odpowiedzialności – kto dostarcza API, projekt graficzny i treści.
2. Jednoznaczna odpowiedź o pracy bez zasięgu i o liczbie ról użytkowników.
3. Opis głównych ścieżek wraz z tym, co dzieje się przy niepowodzeniu.

Dobry brief nie obniża ceny sztucznie. Sprawia, że cena, którą dostajesz, jest ceną, którą zapłacisz.

Rachunek nie kończy się na wdrożeniu. Aplikacja wchodzi potem w tryb utrzymania, w którym pracy jest mniej niż przy budowie, ale nigdy nie spada do zera – szerzej piszemy o tym we wpisie kiedy własny zespół mobilny przestaje się opłacać. Jeśli brief milczy o utrzymaniu, oferty będą nieporównywalne również w tym wymiarze.

Masz już rozpisaną specyfikację? Sprawdź te osiem punktów

Część zamawiających jest na przeciwnym biegunie: przychodzi z gotową, kilkudziesięciostronicową specyfikacją wymagań, napisaną przez własnych analityków. To dobra pozycja wyjściowa i nikt nie każe takiego dokumentu skracać – liczy się to, ile kwestii dokument rozstrzyga.

Przy dłuższych dokumentach zmienia się natomiast rodzaj ryzyka. Zamiast braków pojawiają się dwa inne problemy. Pierwszy to wewnętrzne sprzeczności, gorsze od braków: brak uzupełnia się jednym pytaniem, sprzeczność wymaga decyzji. Drugi jest poważniejszy i dotyczy zwłaszcza zespołów, które specyfikują świetnie, ale nie na urządzenia mobilne – specyfikacja rozstrzyga sto szczegółów interfejsu i milczy o właściwościach platformy, których nikt spoza świata mobilnego nie ma powodu znać. Warto przejść przez nie przed rozesłaniem takiego dokumentu.

1. Wydania nie da się poprawić „na produkcji". Każda zmiana to nowe wydanie przechodzące weryfikację sklepu. Konsekwencja architektoniczna, której specyfikacje prawie nigdy nie zawierają: potrzebna jest zdalna konfiguracja i możliwość wyłączenia pojedynczej funkcji bez publikowania nowej wersji, a często także mechanizm wymuszenia aktualizacji.
2. Stare wersje aplikacji zostają w użyciu równolegle. Część użytkowników nie aktualizuje miesiącami. Warstwa serwerowa musi więc obsługiwać kilka wersji aplikacji naraz – to wymaganie wobec API, którego specyfikacja pisana od strony aplikacji zwykle nie stawia.
3. Uprawnień można odmówić. Aparat, lokalizacja, powiadomienia, pliki, kontakty – użytkownik może odmówić przy pierwszym pytaniu i cofnąć zgodę później w ustawieniach systemu. Każda funkcja oparta na uprawnieniu potrzebuje opisanego wariantu „odmowa", a nie tylko ścieżki właściwej.
4. Praca w tle jest ograniczana przez system. Wymaganie „aplikacja synchronizuje dane co pięć minut w tle" bywa po prostu niewykonalne: obie platformy limitują zadania w tle i bardzo restrykcyjnie ograniczają zużycie baterii. Ten punkt trzeba przeformułować już na etapie specyfikacji – w kodzie się go nie obejdzie.
5. Powiadomienia push nie są kanałem gwarantowanym. Wymagają zgody, którą użytkownik może cofnąć, a ich dostarczenie i moment doręczenia nie są pewne. Nie da się na nich oprzeć procesu krytycznego, w którym powiadomienie jest jedynym nośnikiem informacji.
6. Interfejs nie jest stały. Systemowa skala czcionki, tryb ciemny, rozmiary ekranów i orientacja sprawiają, że układ przeniesiony „na sztywno" z projektu serwisu internetowego rozjeżdża się na realnych urządzeniach – i przy okazji łamie dostępność.
7. Urządzenie jest środowiskiem niezaufanym. Dane, klucze i sesje trzymane na telefonie podlegają innemu modelowi zagrożeń niż te na serwerze. Jeśli specyfikacja mówi o bezpieczeństwie, warto odnieść ją do standardu właściwego dla aplikacji mobilnych, na przykład OWASP MASVS.
8. Powrót z zewnętrznej płatności lub logowania. Przejście do przeglądarki albo aplikacji banku i powrót do właściwego ekranu z zachowanym stanem to osobna praca – w specyfikacjach pisanych z perspektywy serwisu internetowego praktycznie nieobecna.

Jeśli twój dokument ma trzydzieści stron, najtańsze, co możesz zrobić przed rozesłaniem, to dopisać jedno zdanie do każdego z tych ośmiu punktów. Gotową specyfikację można też oddać do przeglądu razem z audytem API i projektu interfejsu – zwykle tańszym niż odkrywanie luk w trzecim miesiącu.

AI w projekcie: co rozstrzygnąć w briefie i o co zapytać dostawcę

Wątek sztucznej inteligencji wchodzi dziś do zapytań ofertowych dwiema drogami naraz: jako funkcja, która ma znaleźć się w aplikacji, i jako sposób pracy dostawcy. Obie wymagają innych pytań.

Jeśli aplikacja ma korzystać z modeli

Funkcja oparta na modelu językowym wnosi do projektu ryzyka, których nie ma w zwykłej integracji: koszt zmienny, niepewny wynik i przepływ danych do zewnętrznego dostawcy. Brief powinien rozstrzygnąć przynajmniej tyle:

• Które dane trafiają do modelu i czy w ogóle mogą opuścić twoją infrastrukturę. Osobno: czy dostawca modelu może ich użyć do trenowania.
• Kto płaci za zapytania i jak ten koszt rośnie z liczbą użytkowników. To wydatek bieżący, który skaluje się wraz z powodzeniem produktu, a nie jednorazowa pozycja wdrożeniowa.
• Co ma się stać, gdy model odpowie błędnie. Kto to wykrywa, czy użytkownik widzi ostrzeżenie i czy istnieje ścieżka do człowieka. Bez tej odpowiedzi wyceniany jest szczęśliwy scenariusz.
• Model w chmurze czy na urządzeniu. Ta decyzja przesądza o działaniu bez zasięgu, o opóźnieniu odpowiedzi i o tym, czy dane w ogóle wychodzą z telefonu.
• Czy funkcja jest krytyczna, czy pomocnicza. Od tego zależy, ile trzeba w nią włożyć testów, zabezpieczeń i pracy nad zachowaniem awaryjnym.
• Czy działasz w obszarze regulowanym. Wtedy użycie modelu bywa przedmiotem osobnej oceny po stronie prawnej lub zgodności, a jej termin trafia do harmonogramu.

Jeśli jeszcze nie wiesz, czy model jest w tym produkcie potrzebny, opisz problem zamiast technologii. To jeden z niewielu obszarów, w których nazwanie rozwiązania w briefie zawęża ofertę bardziej, niż pomaga.

O co zapytać dostawcę

Niezależnie od tego, co ma robić aplikacja, w 2026 roku wypada zapytać każdego wykonawcę, jak sam używa narzędzi AI. Trzy pytania wystarczą:

• W jakim trybie pracują te narzędzia i co dzieje się z materiałami przekazanymi do wyceny. Brief bywa dokumentem wrażliwym; jego treść nie powinna zasilać publicznych modeli.
• Czy każda zmiana w kodzie przechodzi przegląd człowieka. Automatyczna kontrola przed przeglądem to zaleta, automatyczna kontrola zamiast przeglądu to ryzyko, które kupujesz razem z aplikacją.
• Czy projekt nie uzależnia się od jednego dostawcy AI. To pytanie o przewidywalność kosztów i o to, co się stanie, gdy cennik albo warunki się zmienią.

Norbsoft odpowiada na te pytania modelem AI-Augmented Development: agenci wspierają analizę, implementację i przegląd kodu, ale nie podejmują autonomicznych decyzji architektonicznych ani nie zatwierdzają zmian bez nadzoru inżyniera, a materiały klientów przetwarzamy w trybach biznesowych, w których nie trafiają do trenowania publicznych modeli.

Na etapie samego briefu przekłada się to na jedną konkretną korzyść. Narzędzia AI skracają rundę pytań, bo szybciej i pełniej wskazują, czego w dokumencie brakuje, a wtedy dostajesz listę pytań zamiast cichych założeń przyjętych za ciebie. Samych rozstrzygnięć nie zastępują i zastąpić nie mogą: decyzja o tym, kto dostarcza API, ile jest ról i czy aplikacja musi działać bez zasięgu, należy do zamawiającego i tylko on może ją podjąć.

Brief minimalny: dwanaście pytań

Jeśli brief odpowiada na wszystkie poniższe pytania, jest lepszy niż większość zapytań krążących po rynku.

1. Jaki problem rozwiązuje aplikacja i po czym poznasz, że go rozwiązała?
2. Kto z niej korzysta i czy wszyscy użytkownicy widzą to samo?
3. Jakie są główne ścieżki użytkownika (3–5), od początku do końca?
4. Co musi być w pierwszej wersji, a co może poczekać?
5. Kto dostarcza warstwę serwerową i API – i czy już istnieją?
6. Kto dostarcza projekt graficzny?
7. Czy istnieje już aplikacja, którą ta ma zastąpić?
8. Z jakimi systemami aplikacja musi się połączyć i czy mają API?
9. iOS, Android czy oba? Telefon czy również tablet?
10. Czy aplikacja musi działać bez dostępu do sieci – i co dokładnie?
11. Jaki jest termin i czy jest sztywny? Jaki jest rząd wielkości budżetu?
12. Kto po twojej stronie podejmuje decyzje i akceptuje efekty?

Szkielet szablonu do wypełnienia

Dokument na dwie–trzy strony wystarczy. Poniższy szkielet można skopiować i uzupełnić – kolejność pól odpowiada kolejności, w jakiej analizuje się brief po drugiej stronie.

BRIEF – APLIKACJA MOBILNA
Firma / osoba kontaktowa i decyzyjna / data

1. O PROJEKCIE
   Problem do rozwiązania:
   Cel mierzalny:
   Dlaczego aplikacja mobilna:

2. UŻYTKOWNICY
   Kto korzysta / role i różnice między nimi / gdzie i kiedy / szacowana liczba:

3. GŁÓWNE ŚCIEŻKI (3–5, od początku do końca)
   Ścieżka:                            Co się dzieje, gdy się nie uda:

4. ZAKRES
   Musi być w pierwszej wersji / może być później / świadomie poza zakresem:

5. PODZIAŁ ODPOWIEDZIALNOŚCI
   Warstwa serwerowa i API:        [nasza / dostawcy / do ustalenia]   Stan:
   Projekt graficzny:              [nasz / dostawcy / do ustalenia]
   Treści i tłumaczenia:           [nasze / dostawcy]
   Polityka prywatności, regulamin: [nasze / dostawcy]
   Konta w sklepach i publikacja:  [nasze / dostawcy]
   Prawa do kodu i repozytorium:   [przeniesienie / licencja]  Repozytorium u:
   Utrzymanie po wdrożeniu:        [nasze / dostawcy / do ustalenia]  Gwarancja: … mies.

6. STAN ZASTANY
   Istniejąca aplikacja:           [tak / nie]   Zastępujemy wpis w sklepie:
   Dostęp do kont deweloperskich i klucza podpisu:
   Systemy, z którymi trzeba się połączyć:

7. WYMAGANIA TECHNICZNE
   Platformy: [iOS / Android / obie]    Tablet: [nie / iPad / Android / oba]
   Orientacja / języki:
   Praca bez sieci:  [niepotrzebna / ograniczona – co: / pełna]
   Dane wrażliwe i wymogi zgodności:
   Funkcje oparte na modelach AI:  [nie / tak – jakie:]
   Dane, które mogą trafić do modelu:

8. OGRANICZENIA I NASZ WKŁAD
   Termin i czy jest sztywny / budżet (rząd wielkości) / model rozliczeń:
   Kto po naszej stronie testuje i akceptuje, na jakich urządzeniach:
   Kto przygotuje dane testowe i dostępy do systemów:

9. ZAŁĄCZNIKI
   [ ] Makiety lub projekt graficzny   [ ] Dokumentacja API
   [ ] Schemat procesu                 [ ] Dostęp do obecnej aplikacji

10. CZEGO OCZEKUJEMY W OFERCIE
    Struktura wyceny / procedura zmian zakresu / skład zespołu:
    Sposób wykorzystania narzędzi AI po stronie wykonawcy:
    Termin składania ofert i tryb zadawania pytań:

Zderz swój brief z tą listą, zanim go wyślesz

Zanim zapytanie pójdzie do dostawców, warto zobaczyć je ich oczami. Wystarczy dowolny asystent AI i poniższy prompt – wgraj swój brief jako plik i skopiuj treść z ramki. Asystent z dostępem do internetu otworzy podany w niej odsyłacz i będzie pracował na pełnej wersji poradnika; jeśli dostępu nie ma, wystarczą kryteria wypisane w samym prompcie.

Zanim go użyjesz, sprawdź tryb pracy narzędzia. Brief bywa dokumentem wrażliwym – zawiera opis procesów, systemów i czasem dane o skali działalności. Korzystaj z trybu biznesowego, w którym treść nie zasila trenowania publicznych modeli, albo usuń z kopii wrażliwe fragmenty przed wgraniem.

Jesteś doświadczonym analitykiem w firmie wytwarzającej aplikacje mobilne.
Dostajesz brief (zapytanie ofertowe) od potencjalnego klienta. Twoim zadaniem
NIE jest ocena pomysłu ani wycena, tylko wskazanie, czego w dokumencie brakuje.

Kryteria oceny pochodzą z poradnika:
https://www.norbsoft.com/blog/brief-na-aplikacje-mobilna

Jeśli masz dostęp do internetu, otwórz ten adres i pracuj na pełnej wersji –
znajdziesz tam rozwinięcie każdego kryterium, podział odpowiedzialności
w trzech modelach współpracy oraz listę pozycji, których w briefach zwykle
nie ma, a które zawsze są w wycenie. Jeśli dostępu nie masz, oprzyj się
na skróconej liście poniżej i nie dopowiadaj sobie kryteriów spoza niej.

Przeanalizuj załączony brief pod kątem następujących kryteriów:

1. Cel biznesowy i mierzalny wskaźnik sukcesu
2. Użytkownicy, role i różnice w dostępie między nimi
3. Główne ścieżki użytkownika wraz z zachowaniem przy niepowodzeniu
4. Zakres z priorytetami: pierwsza wersja / później / świadomie poza zakresem
5. Podział odpowiedzialności: kto dostarcza API, projekt graficzny, treści,
   politykę prywatności i regulamin, konta w sklepach, utrzymanie, kto ma
   prawa do kodu i gdzie stoi repozytorium
6. Stan zastany: istniejąca aplikacja, dostęp do kont deweloperskich i klucza
   podpisu Androida, dane i subskrypcje do przeniesienia, analityka
7. Integracje: nazwa systemu, czy ma API, czy jest udokumentowane, kto zarządza
8. Wymagania niefunkcjonalne: platformy, minimalne wersje, tablet, orientacja,
   języki, praca bez zasięgu (zakres i maksymalny czas), dostępność, dane
   osobowe i wymogi zgodności, skala
9. Sposób zarabiania, jeśli dotyczy, oraz sprzedaż poza aplikacją
10. Termin i czy jest sztywny; budżet lub choćby rząd wielkości
11. Osoba decyzyjna, tryb odbiorów, zaangażowanie zespołu zamawiającego
    (kto testuje, na jakich urządzeniach, kto przygotuje dane testowe)
12. Oczekiwany format oferty i procedura zmiany zakresu
13. Funkcje oparte na modelach AI: które dane trafiają do modelu, kto płaci
    za zapytania, co przy błędnej odpowiedzi, chmura czy urządzenie

Sprawdź dodatkowo, czy brief odnosi się do właściwości platform mobilnych,
które łatwo pominąć: braku poprawek "na produkcji" i potrzeby zdalnego
wyłączania funkcji, równoległego życia starych wersji aplikacji, możliwości
odmowy uprawnień, ograniczeń pracy w tle, niegwarantowanego dostarczania
powiadomień push, zmiennej skali czcionki i rozmiarów ekranów, powrotu
z zewnętrznej płatności lub logowania.

Zwróć wynik w trzech częściach:

A. TABELA LUK – kolumny: czego brakuje | dlaczego to zmienia wycenę lub termin
   | jakie założenie przyjmie dostawca, jeśli tego nie uzupełnię. Posortuj
   od największego wpływu na cenę.
B. SPRZECZNOŚCI – miejsca, w których brief mówi dwie różne rzeczy. Cytuj oba
   fragmenty.
C. ZDANIA DO DOPISANIA – konkretne, gotowe zdania uzupełniające pięć
   najważniejszych luk, sformułowane tak, żeby dało się je wkleić do briefu.
   Tam, gdzie odpowiedź zależy od decyzji, której nie znasz, zostaw pole
   do wypełnienia zamiast zgadywać.

Nie wymyślaj informacji, których w briefie nie ma, i nie zakładaj branży ani
typu aplikacji, jeśli dokument tego nie precyzuje. Jeśli czegoś nie da się
rozstrzygnąć z treści, wpisz to jako lukę.

Wynik potraktuj jak listę roboczą – ocena, które luki naprawdę trzeba zamknąć, zostaje po twojej stronie. Część pozycji świadomie zostawisz otwartych – to normalne, o ile zapiszesz w briefie, że są otwarte, i poprosisz o wycenę wariantową.

Jeśli chcesz omówić ten szkielet z kimś, kto na co dzień czyta takie dokumenty po drugiej stronie, porozmawiajmy o twoim briefie jeszcze przed wysłaniem zapytania. A jeśli okaże się, że część odpowiedzi trzeba dopiero wypracować, właśnie po to jest Badanie Potrzeb: osobny, krótki etap zamykany specyfikacją. Norbsoft działa od 2003 roku, ma za sobą ponad 200 projektów, a aplikacje z jego udziałem trafiły do użytkowników w 45 krajach (o nas) – w wielu branżach, od handlu elektronicznego po narzędzia terenowe.

Najczęstsze pytania

Jak długi powinien być brief na aplikację mobilną?

Typowy dobry brief mieści się na jednej–pięciu stronach, ale górna granica nie jest regułą – pełna specyfikacja wymagań też bywa świetnym punktem wyjścia. Liczy się liczba zamkniętych kwestii. Przy dłuższych dokumentach rośnie za to ryzyko wewnętrznych sprzeczności, gorszych od braków: brak uzupełnia się jednym pytaniem, sprzeczność wymaga decyzji.

Czy muszę podać budżet w zapytaniu ofertowym?

Nie musisz, ale to działa na twoją korzyść. Obawa, że kwota podbije ofertę, rozmija się z praktyką: wyceny wychodzą wyżej niż wyobrażenie zamawiającego znacznie częściej niż odwrotnie, więc rozmowa i tak dotyczy zmieszczenia zakresu w budżecie. Wystarczy przedział albo granica, powyżej której projekt traci sens.

Nie wiem, czego dokładnie potrzebuję. Czy mam czekać z zapytaniem?

Nie. Napisz to wprost i opisz problem zamiast rozwiązania – samo zdanie „jeszcze tego nie wiemy" jest pełnoprawną odpowiedzią. Rozważ też zamówienie krótkiego etapu analizy jako osobnej pracy. Zwykle jest tańszy niż bufor, który dostawca doliczy do niepewnego zakresu, a jego efektem jest specyfikacja nadająca się do rozesłania kilku firmom.

Czy powinienem od razu przygotować projekt graficzny?

Nie jest to konieczne i bywa kosztowne, jeśli projekt powstanie bez uwzględnienia realiów obu platform – iOS i Android różnią się wzorcami nawigacji oraz zachowaniem standardowych komponentów. Znacznie ważniejsze od gotowych makiet jest rozstrzygnięcie w briefie, kto je wykona, kiedy będą gotowe i kto je akceptuje.

Czy warto wysłać ten sam brief do kilku firm?

Tak, pod warunkiem że jest to ten sam dokument i że rozstrzyga podział odpowiedzialności. Inaczej porównujesz oferty na różne projekty. Przy porównywaniu czytaj najpierw sekcję założeń każdej oferty, dopiero potem cenę – dwie wyceny różniące się dwukrotnie zwykle różnią się właśnie założeniami, a nie stawką godzinową.

Brief zawiera wrażliwe informacje o naszych procesach. Ile z nich wyciąć?

Jak najmniej. Im więcej wytniesz, tym szerszy przedział wyceny dostaniesz, bo dostawca musi te braki zabezpieczyć buforem. Umowa o poufności jest tańsza niż bufor. Alternatywa to brief dwustopniowy: wersja kwalifikacyjna dla wszystkich, szczegółowa po podpisaniu umowy.

Ile trwa przygotowanie wyceny aplikacji mobilnej?

Zależy głównie od jakości briefu. Kompletny dokument pozwala zwykle odpowiedzieć w kilka dni, bo nie wymaga rundy pytań i odpowiedzi. Brief, który taką rundę wymusza, wydłuża termin o tyle, ile zajmie zebranie odpowiedzi po stronie zamawiającego – a to trwa zwykle dłużej, niż się zakłada.

Czy mogę zmienić zakres w trakcie projektu?

Tak, praktycznie zawsze się to dzieje – w projekcie cyfrowym zmiana zakresu jest zjawiskiem normalnym. Chodzi o to, żeby dotyczyła rzeczy, o których obie strony dowiedziały się w trakcie, a nie tych, które dało się rozstrzygnąć na początku. Dlatego w briefie warto poprosić o opis procedury zmian: kto zgłasza, kto wycenia i kto akceptuje. Odpowiedź mówi o dostawcy więcej niż referencje.