[Spis treści]Pokaż spis treści
W 2016, z Krzysztofem P., dealerem Cupry w Krakowie, na kartce: VIN-tracker za 200k PLN w Excelu. Tak zaczęło się Do More Soft. Dziś mamy 12 własnych produktów, zespół kilkunastu specjalistów i ponad 80 zrealizowanych projektów. Droga nie była liniowa i dlatego warto ją opowiedzieć.
Początki: automotive jako szkoła przetrwania
Pierwszy poważny projekt to system dla dealera samochodów. Integracja z fabryką, śledzenie VIN-ów, kalkulator finansowania. Automotive nauczył nas dwóch rzeczy: złożone procesy biznesowe wymagają głębokiego zrozumienia domeny, a klienci nie chcą „oprogramowania”. Chcą rozwiązania swojego problemu. Ta lekcja definiuje nas do dziś.
W pierwszych 18 miesiącach dowoziliśmy projekty, brakowało pieniędzy, nie wiedzieliśmy co klient robi z kodem. Czuło się jak porażka, choć rachunki pokazywały sukces. Model liniowy, przewidywalny, ale ograniczony. Brakowało nam poczucia współwłasności nad tym, co budujemy.
Punkt zwrotny: decyzja o własnych produktach
W 2020 miałem dylemat. Zatrudniać devów i sprzedawać godziny, czy zbudować produkt. Wybór zrobił się sam, gdy przegraliśmy o włos tender na 300k. Wtedy zaczęliśmy budować własne produkty. Nie dlatego, że nie mieliśmy klientów. Dlatego, że widzieliśmy powtarzające się problemy u wielu firm i wiedzieliśmy, że potrafimy je rozwiązać systemowo.
To był ryzykowny ruch. Budowanie własnych produktów wymaga inwestycji czasu, pieniędzy i energii, która mogłaby pójść na projekty komercyjne. Ale dało nam coś, czego nie da żaden projekt na zlecenie: skin in the game. Kiedy budujesz produkt, który sam musisz utrzymywać i rozwijać, podejmujesz inne decyzje architektoniczne niż kiedy oddajesz kod i odchodzisz.
Czym różni się software house od venture buildera?
Klasyczny software house ma ukryty konflikt interesów: im dłużej trwa projekt, tym więcej zarabia. Venture builder zarabia na sukcesie produktu, nie na godzinach wypalonych na projekcie. To fundamentalna różnica w incentivach, która przekłada się na każdą decyzję — od wyboru technologii po zakres MVP.
Kiedy budujemy produkt na własny rachunek, musimy być bezwzględnie pragmatyczni. Nie pozwolimy sobie na overengineering, bo to nasze pieniądze. Nie zignorujemy feedbacku użytkowników, bo to nasi klienci. Nie zbudujemy i nie porzucimy, bo to nasz P&L. Dyscyplina przenosi się na projekty robione dla klientów. Nauczyliśmy się myśleć jak właściciele, a nie jak podwykonawcy.
Venture Builder vs. Software House: kluczowe różnice
| Wymiar | Software House | Venture Builder |
|---|---|---|
| Model przychodu | Faktury za godziny | Współwłasność produktu, equity, success fee |
| Horyzont decyzji | Do oddania projektu | 3-5 lat operacji produkcyjnej |
| Architektura | Pod demo i odbiór | Pod utrzymanie i skalowanie |
| Estymacje | Optymistyczne (wygrana w tenderze) | Realistyczne (zbudowaliśmy podobne) |
| Decyzje scope’u | „Klient chce, robimy” | „MVP czy nice-to-have?” |
| Skin in the game | Brak po deploymencie | Trzy lata po deploymencie |
12 produktów — co budujemy i dlaczego
MoreSales powstał ze zmęczenia. MyCarApp bo dealerów nauczyliśmy się od Cupry. OpenEZD bo administracja publiczna mnie męczyła osobiście. Tak rodzi się większość produktów w ekosystemie: nie z research deck’u, tylko z bólu, który ktoś z nas zobaczył z bliska.
Ekosystem obejmuje MoreSales i MoreCRM (CRM/ERP), platformy branżowe — MyCarApp dla automotive, DailyHair dla beauty, CalMedic dla medtech, Kwadracik dla nieruchomości — obieg dokumentów (OpenEZD, MoreGenerator), AI i content (Textio), oraz narzędzia MoreNFC, MoreMobile i GetMeCon.
DailyHair jest dobrym przykładem venture buildingu w praktyce. Branża beauty potrzebowała systemu rezerwacji, który nie jest generycznym Booksy. Systemu rozumiejącego specyfikę salonów fryzjerskich i barberów. Zbudowaliśmy go, wdrożyliśmy w pilotażowych salonach, iterowaliśmy na podstawie feedbacku i skalujemy jako niezależny produkt.
Co znaczy skin in the game w partnerstwach software?
Klient, który przychodzi do software house’u, dostaje zespół, który pisał kod. Klient, który przychodzi do venture buildera, dostaje zespół, który budował, uruchamiał, utrzymywał i skalował własne produkty. Różnica jest w doświadczeniu operacyjnym. Wiemy, co dzieje się po deploymencie, bo żyjemy z tego, co wdrożyliśmy.
Konkretnie oznacza to: realistyczne estymacje (budowaliśmy podobne systemy na własny rachunek, wiemy ile co trwa), architekturę pod utrzymanie zamiast pod demo (sami utrzymujemy produkty latami) oraz pragmatyczne decyzje scope’u (wiemy, co jest MVP, a co nice-to-have, bo wielokrotnie podejmowaliśmy te same decyzje dla siebie).
Lekcje z dekady budowania
Pierwsza lekcja: perfekcja jest wrogiem dostarczenia. Lepiej wydać solidne 80% niż doskonałe 100%, które nigdy nie wyjdzie na produkcję. Druga: technologia to dźwignia, nie cel. Klienta nie obchodzi, czy używasz React czy Vue. Obchodzi go, czy system rozwiązuje jego problem. Trzecia: zespół jest ważniejszy niż stack. Dobry programista w przeciętnej technologii daje lepsze wyniki niż przeciętny programista w najnowszej.
Najtrudniejsza lekcja: mów „nie”. W 2023 klient z budżetem 500k na SaaS dla logistyki. Powiedziałem nie. Nie mamy domain expert, nie mamy referencji. Źle dobrany projekt kosztuje więcej niż brak projektu. To trudna lekcja dla firmy, która chce rosnąć, i kluczowa dla firmy, która chce rosnąć mądrze.
Wizja: co dalej
Nie chcemy być HR-em dla softwareu. Chcemy być operatorami produktów wiedzącymi, co się stanie w roku trzecim, bo tam już jesteśmy. Model: venture builder, który dzieli ryzyko i zysk z partnerami, zamiast wystawiać faktury za godziny.
W ciągu najbliższych dwóch lat chcemy rozwinąć ekosystem do 15-18 produktów, wejść mocniej w rynki DACH i CEE, i zbudować platformę technologiczną pozwalającą szybciej uruchamiać nowe produkty — ze wspólną warstwą autentykacji, płatności, analityki i infrastruktury. Nie budujemy software house’u. Budujemy maszynę do tworzenia wartości cyfrowej.
FAQ
Jak model venture buildera różni się od klasycznego developmentu?
Klasyczny development to faktury za godziny. Venture builder zarabia na sukcesie produktu — przez współwłasność, equity albo success fee. To zmienia każdą decyzję: od stacku po zakres MVP, od architektury po SLA.
Dlaczego venture builderzy podejmują lepsze decyzje architektoniczne?
Bo sami żyją z konsekwencjami. Software house oddaje kod i wystawia fakturę. Venture builder utrzymuje produkt trzy lata po wdrożeniu, więc nie zbuduje czegoś, czego nie chce pielęgnować. Decyzje są pragmatyczne, nie pokazowe.
Czy Do More Soft pracuje też w modelu zlecenia?
Tak, ale selektywnie. Bierzemy projekty, w których możemy zastosować know-how z własnych produktów — automotive, beauty, medtech, GovTech, nieruchomości. Projekty „cokolwiek, byle programista” odrzucamy.