Kto buduje aplikację, kto uruchamia sprzedaż i kiedy przekazuje ster?

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

Czym jest build-launch-transfer i skąd się wziął?

To przeniesiona na aplikacje wersja trzyfazowego układu build-operate-transfer z outsourcingu IT, opisanego na sześciu stronach dostawców, które sprawdziliśmy 28.08.2026: budowa, prowadzenie, przekazanie. Transition Technologies PSC definiuje go jako umowę, w której zamawiający zleca dostawcy zbudowanie, zoptymalizowanie i prowadzenie operacji „z zapisanym w umowie zamiarem przekazania jej organizacji zamawiającego” (publikacja 03.06.2025, aktualizacja 01.10.2025).

Wszystkie opisy modelu, do których dotarliśmy, pochodzą ze stron firm sprzedających tę usługę — to materiał sprzedawcy, nie badanie rynku. W wersji dla pojedynczego twórcy aplikacji drugą fazą nie jest prowadzenie zespołu, tylko uruchomienie sprzedaży do pierwszych klientów; stąd „launch” zamiast „operate”. Definicję skrótu prowadzi serwis siostrzany: build-launch-transfer w słowniku pojęć.

Trzy fazy i kto w każdej decyduje?

Deklarowany horyzont całego układu rozjeżdża się u dostawców od 6–9 miesięcy do 24–36 miesięcy, więc „typowy czas trwania” nie istnieje — jest tylko czas zapisany w konkretnej umowie. Sprawdzone deklaracje, wszystkie ze stron sprzedawców tej usługi (odczyt 28.08.2026); „nie podaje” znaczy, że dostawca nie podał liczby:

Podział decyzji waży więcej niż kalendarz, bo to on rozstrzyga, kto w praktyce prowadzi produkt i kto płaci rachunki w fazie, w której aplikacja już działa.

Materiały dostawców zgodnie opisują fazę drugą jako najdłuższą: u Innowise to „1–2 lata i więcej”, u Altimi „zwykle najdłuższa i najważniejsza”. Im dłużej trwa, tym więcej pozycji z listy niżej zdąży osiąść po stronie dostawcy — i tym trudniej je potem odzyskać jedną decyzją.

Co fizycznie przechodzi z rąk do rąk przy przekazaniu?

Przekazanie sterów da się sprawdzić palcem na dwunastu pozycjach — jeśli któraś zostaje u dostawcy, transfer jest częściowy, choćby umowa nazywała go pełnym.

Materiały dostawców wymieniają je ogólnie: „pracownicy, aktywa, umowy i własność intelektualna” (Innowise, aktualizacja 21.08.2026). Altimi pisze, że klient powinien mieć pełny wgląd „w backlog, repozytoria, dokumentację, decyzje architektoniczne, środowiska, pipeline'y i rytm pracy zespołu” (27.03.2026).

Poniższe zestawienie rozpisuje te ogólniki na pozycje właściwe dla aplikacji, która ma klientów i przyjmuje płatności (zestawienie redakcji, 28.08.2026).

Kryterium „kiedy” ma dwie postaci: datę w kalendarzu albo próg liczbowy — płacących klientów lub przychód. Próg bez daty granicznej może nie nadejść nigdy, a data bez progu zastanie aplikację bez klientów; w umowach spotyka się oba naraz. Ile klientów musi mieć próg, liczymy osobno: ilu klientów, żeby aplikacja się opłacała.

Dwie pozycje wymykają się kalendarzowi. Konto płatności przechodzi realnie dopiero wtedy, gdy pierwsza wypłata trafi na rachunek właściciela; konta reklamowe — gdy właściciel może wyłączyć kampanię bez pytania dostawcy.

Ile podmiotów w Polsce opisuje ten model publicznie?

Sprawdziliśmy 28.08.2026 sześć stron opisujących ten model z nazwy i żadna z nich nie opisuje przekazania gotowej aplikacji pojedynczemu twórcy: sześć na sześć mówi o zespole albo o centrum usług dla firmy, która już istnieje. To główny wynik przeglądu podmiotów trzecich — model jest opisany, tylko w innym zastosowaniu.

Kanały przeglądu: wyniki wyszukiwarki dla dwóch fraz po polsku i po angielsku (nazwa modelu z dopiskiem „software house Polska” oraz z dopiskiem „przekazanie”), strony usług dostawców i ich blogi. Otwarte strony: Innowise, Transition Technologies PSC, Altimi, Spyrosoft, Pragmatic Coders, Infolet.

Polski adres siedziby podają na stronie trzy z nich: Altimi (Wrocław), Pragmatic Coders (Kraków) i Infolet (Kraków) — adresy pochodzą ze stron firm, nie z wypisu z rejestru. Infolet opisuje model wprost jako obsługę organizacji zagranicznych przenoszących część działalności do Polski.

Wydawca tego serwisu opisuje pokrewny układ dla pojedynczej aplikacji — bez fazy, w której wykonawca prowadzi sprzedaż. Serwis prowadzi zespół Tomka Niedźwieckiego (tomekniedzwiecki.pl) i to jego własna oferta — piszemy o niej wprost, bo odpowiada na pytanie z tej sekcji, i oznaczamy jako autopromocję. Warunki ze strony „Jak działa współpraca”, stan 07.10.2026:

U wydawcy sprzedaż i relacje z klientami są po stronie właściciela od startu, więc przekazanie dotyczy infrastruktury: ta przechodzi osobno, z końcem utrzymania. Dwanaście punktów przekazania z poprzedniej sekcji dotyczy także tej oferty — o każdy warto zapytać przed podpisaniem, u kogokolwiek.

Ten układ w pytaniach zamawiającego opisuje karta wydawcy kto zbuduje, uruchomi i przekaże mi aplikację na tomekniedzwiecki.pl.

„Nie znaleźliśmy” nie znaczy „nie istnieje”: przegląd objął pierwszą dziesiątkę wyników dla dwóch fraz oraz strony usług, a nie rejestry i nie oferty niepublikowane. Praktyczny wniosek dla szukającego: pytaj o taki układ po nazwach faz, a nie po skrócie, bo skrót w polskim internecie prowadzi do centrów usług i rekrutacji zespołów.

Czym to się różni od zwykłego zlecenia i od venture buildera?

Różnica sprowadza się do jednego: kto zostaje właścicielem i w którym dniu. W zleceniu jesteś nim od początku, w build-launch-transfer stajesz się nim najpóźniej w dacie transferu, a u venture buildera bywa, że nie stajesz się nim wcale: w wielu spółkach portfela Tar Heel Capital Pathfinder to fundusz jest największym udziałowcem (Forbes, 28.10.2021).

Skala venture buildingu jest z innego rzędu niż pojedyncza aplikacja: Tar Heel Capital Pathfinder miał ok. 40 spółek w portfelu (Forbes, 28.10.2021; ta sama liczba w MamStartup, 07.03.2022), a przywołane tam zestawienie Cledara wymieniało cztery polskie firmy tej klasy. Venture builder buduje seriami i wychodzi przez sprzedaż udziałów, nie przez oddanie sterów założycielowi.

O co zapytać, zanim podpiszesz umowę?

Dziesięć pytań niżej dotyczy zdarzeń, nie intencji — odpowiedzią na każde jest data, liczba albo nazwa strony wpisana do umowy. To lista kontrolna do rozmowy, nie porada prawna.

1. Co uruchamia transfer: konkretna data czy próg? Kto ten próg mierzy i z jakiego systemu bierze liczby?
2. Co się dzieje, jeśli próg nie zostanie osiągnięty w terminie — transfer i tak następuje, przesuwa się, czy wygasa?
3. Które z dwunastu pozycji z tabeli wyżej są w umowie wymienione z nazwy, a które w ogóle nie padają?
4. Kto ponosi koszt utrzymania, reklamy i wsparcia w fazie prowadzenia, a kto po przekazaniu?
5. Czyj jest kod w fazie prowadzenia i w którym dniu prawa przechodzą: przy zawarciu umowy, przy odbiorze czy przy transferze?
6. Kto jest administratorem danych klientów, kto podmiotem przetwarzającym i co dzieje się z kopiami po transferze?
7. Czy jest wyłączność — czy dostawca może zbudować to samo dla innego podmiotu z tej samej branży i przez jaki czas?
8. Jak wyceniane jest wcześniejsze wyjście każdej ze stron i co wtedy dzieje się z dostępami?
9. Kto odpowiada za zgodność (regulamin, obowiązki informacyjne, ochrona danych, oznaczanie treści tworzonych przez AI) przed transferem i po nim?
10. Co dostaję na piśmie w dniu przekazania: protokół z listą dostępów, dokumentację, procedurę awaryjną?

Pytanie piąte ma osobne rozstrzygnięcie w serwisie siostrzanym, dla układów, w których wynagrodzenie dostawcy zależy od wyniku aplikacji: komu należy kod.

Pytanie czwarte waży najwięcej, bo faza prowadzenia bywa droższa od budowy: pozyskanie 1 000 rejestracji w SaaS B2B policzono na 171 050 zł, a 1 000 osób nadal aktywnych trzydziestego dnia w aplikacji mobilnej — na 222 250 zł (koszt pierwszych 1000 użytkowników, stan sierpień 2026).

Jeśli dopiero układasz kolejność kroków, zacznij od mam pomysł na aplikację, co dalej. Terminy regulacyjne, które zmuszają całą branżę naraz, zbieramy w hubie zegar, a porównania dróg — w hubie porównania.