Budowanie DailyHair — od zera do 200 wydarzeń obsłużonych w 12 miesięcy

W II kwartale 2025, na konferencji Cupra w Warszawie z 47 partnerami medialnymi, dostaliśmy mail od koordynatorki o 22:47: „Czwarty raz w tym tygodniu Forbes przesuwa deadline. Wyborcza chce inny brief niż TVN24. Mam to wszystko w Excelu na trzech zakładkach, ale o 6:00 jutro muszę wysłać 47 osobnych podsumowań i już nie wiem, kto na czym stoi.” W załączniku zrzut ekranu arkusza, w którym kreskami odnotowała deadline’y uzgodnione przez telefon. Dwie godziny później była konferencja branżowa, którą współorganizowaliśmy — pierwsza, na której zobaczyliśmy ten sam pattern u trzech kolejnych managerek komunikacji. W tym samym tygodniu zaczęliśmy budować DailyHair.

Liczba „47 patronów medialnych” nie była imponująca sama w sobie. Była symptomem architektury operacyjnej, której nie obsługuje żadne generyczne narzędzie do eventów. Manager komunikacji nie organizowała wydarzenia, tylko gasiła pożary między dwoma światami: organizatorem, który chce maksimum widoczności, i mediami, które chcą maksimum wartości za swój patronat.

W DailyHair od początku zbiegły się trzy warunki, których szukamy w każdym partnerstwie venture-building. Pierwszy: ekspertka z 12 latami w PR eventowym i listą 30 zaprzyjaźnionych organizatorów gotowych przetestować produkt — to nie była hipoteza, tylko dystrybucja na start. Drugi: rynek wart 1500 polskich konferencji rocznie obsługujących patronatów medialnych, z którego 15% to już 200+ klientów SaaS. Trzeci, najtrudniejszy: zerowa tolerancja partnerki dla oprogramowania wymagającego dwugodzinnego onboardingu w środku sprintu eventowego — co operacyjnie oznaczało, że każdy feature musiał działać w 5 minut albo nie istniał. Te trzy warunki operacyjnie wyglądały jak rzadki moment, w którym pomysł, dystrybucja i dyscyplina scope’u są w jednej parze rąk.

Dlaczego nie zbudowaliśmy kolejnego Eventbrite

Eventbrite, Evenea, Konfeo są dobre dla masy. To pragmatyczne narzędzia dla organizatora, który chce „mieć biletowanie online” i nie różnicować się niczym ponadto. Ale rynek, który nas interesował — wydarzenia branżowe i konferencje z budżetem od 200 tys. zł wzwyż, gdzie patronat medialny i sponsoring stanowią znaczącą część finansowania — ma specyficzne potrzeby, których generyczna platforma do biletów nie adresuje.

Po pierwsze: zarządzanie patronatami medialnymi jako pierwszorzędny obiekt. Patronat to nie „bilet z kategorii FREE”. To umowa z mediami, w której obie strony mają zobowiązania (publikacja zapowiedzi, post w social media, banner na konferencji w zamian za logo, wzmiankę i puli biletów). Każdy patronat ma swój brief, swój pakiet materiałów, swoje deadline’y, swoje raporty z post-eventu. Brakowało narzędzia, które rozumie tę dwukierunkową umowę natywnie.

Po drugie: pakiety patronackie. Patron główny plus patron prasowy plus patron radiowy plus patron internetowy to nie cztery osobne kontrakty, tylko jedno wydarzenie z wariantowym pakietem dla każdego poziomu. Eventbrite obsługuje to słabo — platforma wymusza sztywny katalog ról, który nie odpowiada rzeczywistym hierarchiom partnerstwa medialnego.

Po trzecie: reguły mediów. „Wyborcza” publikuje tylko zapowiedzi 21 dni przed wydarzeniem, „Forbes” wymaga ekskluzywnego wywiadu z prelegentem, lokalna stacja radiowa potrzebuje gotowego spotu w MP3. W generycznym narzędziu każde medium dostaje ten sam brief. W realnym managementcie patronatów każdy partner ma własny rytm, format i checklist deliverables. Potrzebowaliśmy systemu, który rozumie te reguły natywnie, a nie obchodzi je przez komentarze w arkuszach.

Po czwarte: rozliczenie wartości patronatu w EAV (Equivalent Advertising Value), nie w biletach. Patron medialny wraca do organizatora, który dał mu zwrot 4-6× w postaci publikacji, ekspozycji na evencie i danych post-eventowych. Nie do organizatora, który dał mu pulę biletów. Rozliczenie wartości to fundament odnowienia patronatu. W praktyce oznaczało to inny model danych niż w typowym SaaS eventowym: medium jako pierwszorzędny obiekt z historią ROI, wydarzenie jako kontener.

Venture Builder vs. Software House — co wybierają scale-upy?

Wymiar	Software House	Venture Builder
Model rozliczenia	Faktura za godziny / scope	Zredukowany flat fee + equity w spółce
Horyzont decyzji	Do odbioru projektu	5+ lat, wspólny P&L
Optymalizacja pod	Zakres i budżet	Retention, MRR, ARR
Kto bierze ryzyko produktu	Klient	Obie strony — udziałowcy
Decyzja o feature	„Klient prosi, my budujemy”	„Czy to ruszy retention?”
Co dzieje się po deploy	Faktura, support hourly	Zespół zostaje — to jego firma
Profil partnera	Każdy z budżetem	Ekspert branżowy + dystrybucja + skala

Scale-upy z dystrybucją na start (lista 30+ zaprzyjaźnionych użytkowników, kontrakty pilot na konferencjach, walidacja niszy) wybierają venture builder, bo dyscyplina scope’u i wspólny upside kompresują 24 miesiące do 12. Reszta — software house, faktura, jasna granica. Pełen framework opisaliśmy w usługach venture builder.

Model: venture building, nie projekt na zlecenie

Klientka przyszła z pomysłem, dwunastoma latami doświadczenia w PR i komunikacji eventowej oraz listą 30 zaprzyjaźnionych organizatorów branżowych, którzy obiecali przetestować produkt. My przyszliśmy z technologią, doświadczeniem w budowaniu i skalowaniu SaaS oraz architekturą biznesową, której nauczyliśmy się przy 11 innych produktach w ekosystemie Do More Soft Venture Builder.

Mogliśmy wycenić projekt jako dedykowane oprogramowanie — około 380-420 tysięcy złotych za MVP plus utrzymanie. Mogliśmy zrobić to w trybie T&M z dwumiesięcznym buforem i zwykłą fakturą. Mogliśmy zaproponować klasyczny fixed price z karami umownymi za opóźnienia. Mogliśmy nawet odmówić, bo skala wydarzeniowego rynku PL jest mniejsza niż większość pomysłów, które trafiają na nasze biurko.

Zamiast tego zaproponowaliśmy strukturę spółki, w której zostaliśmy współudziałowcami, a nasze wynagrodzenie za pierwsze 12 miesięcy zostało zredukowane do pokrycia podstawowych kosztów zespołu. Różnica między wyceną rynkową a realnie wypłaconą kwotą stała się naszą inwestycją w udziały.

To decyzja, która zmienia wszystko. Software house optymalizuje pod zakres projektu i budżet. Venture builder optymalizuje pod wskaźniki retencji, MRR i ARR. Nie budujesz featurów na zapas, bo każda godzina niepotrzebnej pracy zmniejsza wartość twojej inwestycji. Nie ignorujesz feedbacku użytkowników, bo to twoi klienci. Nie odchodzisz po odebraniu faktury, bo nie ma faktury — jest wspólny P&L. Skin in the game to nie slogan, to narzędzie dyscypliny scope’u.

Fazy budowy — od pomysłu do 200 wydarzeń

Cały cykl — od pierwszej rozmowy z klientką do 200 obsłużonych wydarzeń — zajął 12 miesięcy. Podzieliliśmy go na cztery rozłączne fazy z jasnymi kryteriami przejścia między nimi.

Faza 1: Discovery (4 tygodnie)

Cztery tygodnie z organizatorami i mediami, zanim padła pierwsza linijka kodu. 22 wywiady — z managerami komunikacji konferencji branżowych, z redaktorami sekcji eventowych w portalach, z dyrektorami marketingu mediów regionalnych. Każdy wywiad to dwie godziny obserwacji workflow plus godzina strukturalnych pytań.

Z tych 22 wywiadów wynikało coś, czego nie założylibyśmy w żadnym pre-discovery brainstormie: managerki komunikacji nie potrzebują „lepszej platformy eventowej”. Potrzebują systemu, który zdejmie z nich rolę żywego API między 47 redakcjami. Ta jedna obserwacja zdefiniowała architekturę — i wycięła z roadmapy trzy moduły, które wcześniej wydawały się oczywiste.

Wynik był zaskakujący w innym wymiarze. Trzy największe punkty bólu nie dotyczyły samego biletowania ani strony eventu. Pierwszym była fragmentacja kanałów komunikacji z patronami (mail + Messenger + Slack zewnętrzny + WeTransfer + telefon). Drugim — brak widoczności statusu materiałów patronackich w czasie rzeczywistym (organizator nie wie, czy „Wyborcza” już wysłała zapowiedź, czy jest w buforze redakcyjnym, czy redaktor czeka na poprawione zdjęcie). Trzecim — brak twardych danych do rozliczenia wartości patronatu post-event (ile osób z jakiego medium dotarło, ile publikacji się ukazało, jaki był łączny zasięg vs. wartość rynkowa pakietu).

To odkrycie zdefiniowało architekturę produktu. DailyHair nie miał być „platformą do biletów” — miał być operacyjnym systemem zarządzania patronatami i komunikacją wokół wydarzenia. Ten reframing zaoszczędził nam trzy miesiące pracy nad zakresem, który nie miałby znaczenia dla użytkowników. Nasz discovery process to filtr — i tym razem zadziałał zgodnie z projektem.

Faza 2: MVP (8 tygodni)

Osiem tygodni na trzy rzeczy: zarządzanie patronatami medialnymi (CRUD partnerów, pakiety, deadline’y deliverables), centrum materiałów (briefy, assety, wersje robocze, akceptacje) oraz dashboard statusów (kto co, na kiedy, w jakim statusie). Zero biletowania. Zero aplikacji mobilnej. Zero analityki poza podstawowymi metrykami produktowymi. Żadnych integracji z zewnętrznymi narzędziami komunikacyjnymi.

Osiem tygodni to nie tempo — to filtr. Jeśli w tym czasie nie uda ci się dostarczyć użytkownikom czegoś, co jest w stanie ocenić, projekt ma strukturalny problem — albo w zakresie, albo w architekturze, albo w zespole. W DailyHair zakres zmieścił się w ośmiu tygodniach dlatego, że odcięliśmy wszystko, co nie było niezbędne do pierwszego realnego testu z konferencją.

Stack wybraliśmy pragmatycznie: React na frontendzie, Node.js z Express na backendzie, PostgreSQL jako baza danych, deploy na AWS ECS z S3 do przechowywania assetów patronackich (logo, zdjęcia, banery, pliki audio dla spotów radiowych). Żadnych eksperymentów technologicznych, żadnego overengineringu. Celem było dotarcie do pierwszego użytkownika, nie zbudowanie platformy na dziesięć lat.

Faza 3: Pilot (3 miesiące)

Osiem konferencji branżowych w pierwszym kwartale 2025 roku — od kameralnych meetupów technologicznych w Krakowie (200-400 uczestników) po dwie duże konferencje marketingowe w Warszawie (1500-2000 uczestników), wśród nich wspomniana konferencja Cupra z 47 patronami medialnymi. Każdy event z bezpośrednim onboardingiem prowadzonym osobiście przez współzałożycielkę produktu. Feedback loop 48-godzinny — każda zgłoszona uwaga otrzymywała odpowiedź (nawet jeśli brzmiała „tego nie zrobimy”) w ciągu dwóch dni roboczych, a jedna na pięć trafiała do backlogu z priorytetem do wdrożenia w ciągu tygodnia.

Pilot ujawnił trzy rzeczy, których nie przewidzielibyśmy przez żadną ilość discovery. Pierwszą: managerowie komunikacji nie chcą się logować do platformy do akceptacji materiałów — chcą zatwierdzać przez link w mailu, bez konta. To przewróciło nasze założenia UX i wymusiło zaprojektowanie „magic-link approval flow” dla patronów. Drugą: organizatorzy chcą widzieć łączne EAV (Equivalent Advertising Value) wszystkich patronatów na bieżąco, nie dopiero w raporcie post-event — bo to argument dla sponsorów komercyjnych do powiększenia kontraktu. Trzecią: redaktorzy w mediach wymagają od organizatora gotowych „press kitów” w ciągu 24h od potwierdzenia patronatu — wcześniejsza wersja DailyHair nie miała tego flow w MVP, dodaliśmy w trzecim sprincie pilotażu.

Trzy miesiące pilotu to była najcenniejsza inwestycja w całym projekcie. Bez niej skalowalibyśmy produkt, który nie odpowiada na realne potrzeby użytkowników.

Faza 4: Skalowanie (6 miesięcy)

Z ośmiu wydarzeń pilotażowych do dwustu obsłużonych. W tej fazie uruchomiliśmy aplikację mobilną we Flutterze (jedna baza kodu na iOS i Android) dla onsite event managerów, integrację z Google Calendar i Outlook do synchronizacji deadline’ów patronackich, automatyczne raporty post-event w PDF dla każdego patrona oraz integrację z platformami do monitoringu mediów (Press-Service, Newspoint) do automatycznego zliczania publikacji. Growth odbywał się w dwóch kanałach: word-of-mouth między organizatorami (przeciętnie każdy obsłużony event polecił 1,7 kolejnego organizatora w pierwszym kwartale po wydarzeniu) oraz referral program wśród managerów komunikacji (manager zmieniający pracodawcę zabierał ze sobą doświadczenie z DailyHair i naturalnie promował platformę u nowego organizatora).

Przez sześć miesięcy skalowania nie wydaliśmy złotówki na reklamę płatną. ROI z word-of-mouth był na tyle wysoki, że każde wydanie na paid marketing byłoby suboptymalne względem inwestycji w jakość onboardingu i szybkość odpowiedzi supportu. Ta decyzja wymagała dyscypliny — presja „zacznijmy reklamować się na LinkedIn” wracała co miesiąc — ale matematyka jej nie uzasadniała.

Technologia jako dźwignia, nie cel

Stack technologiczny DailyHair to świadomie konserwatywne wybory. React, Node.js i PostgreSQL to kombinacja, w której zespół ma najwięcej ekspertyzy, a ekosystem bibliotek i narzędzi jest najgłębszy. Nie szukaliśmy przewagi w warstwie technologicznej — szukaliśmy przewagi w tempie dostarczania i jakości UX. Ten sam framework decyzyjny zastosowaliśmy w Cupra mycarapp, gdzie warstwa technologiczna miała być niewidzialna, a produkt mierzony retention.

Magic-link approval (zamiast pełnego logowania dla patronów) to decyzja, która usunęła największe tarcie w adoptcji wśród mediów. Redaktor dostaje link w mailu, klika, akceptuje materiał lub odrzuca z komentarzem, gotowe. Zaoszczędziliśmy w ten sposób co najmniej trzy miesiące pracy nad systemem ról i uprawnień, a jednocześnie podnieśliśmy odpowiedź patronów z ~40 procent do ponad 80 procent w pierwszym kwartale.

Flutter zamiast natywnych aplikacji iOS i Android to decyzja oparta na matematyce: jedna baza kodu, jeden zespół mobilny, jedno tempo iteracji. Tracimy około 15 procent natywnej perfekcji UI, zyskujemy dwukrotnie szybszy cykl rozwoju i dwukrotnie niższy koszt utrzymania. W fazie wzrostu 40 procent miesięcznie tempo jest ważniejsze niż natywna perfekcja.

AWS S3 do assetów patronackich to oczywistość — storage bez infra ownership, wbudowany CDN (CloudFront), marginalny koszt per event. Ten sam argument: nie buduj infrastruktury, której nie musisz budować. Szczegółową logikę doboru stacku opisaliśmy w kontekście dedykowanego oprogramowania — to ten sam framework decyzyjny, który stosujemy w każdym projekcie venture buildingu.

Pierwszy rok — co działało, co nie

Brutalnie uczciwy rachunek za 12 miesięcy.

Co działało. Word-of-mouth między organizatorami okazał się znacznie silniejszym kanałem niż zakładaliśmy — branża eventowa jest gęsto usieciowiona, managerowie komunikacji znają się osobiście, a rekomendacja od zaprzyjaźnionego organizatora waży więcej niż case study i demo razem wzięte. Centrum materiałów z magic-link approval — feature, którego konkurencja nie miała w ogóle — stał się głównym argumentem sprzedażowym; ponad 70 procent organizatorów przyznało w ankiecie po pierwszym evencie, że właśnie ta funkcjonalność przeważyła o decyzji wyboru DailyHair. Raporty EAV post-event pokochali dyrektorzy marketingu — okazało się, że zaspokajają potrzebę twardego dowodu wartości patronatu medialnego, którego nie daje żadne inne narzędzie (Excel zliczany ręcznie po evencie nikogo nie przekonuje).

Co nie działało. Pierwsza wersja powiadomień email do patronów miała open rate 24 procent — dużo poniżej benchmarku branżowego dla B2B. Po analizie okazało się, że template wyglądał jak transactional notification z systemu SaaS, a nie jak osobista wiadomość od managera komunikacji. Przeprojektowaliśmy szablony do formatu „personal email z linkiem”, open rate skoczył do 62 procent. Pierwszy try-and-buy dla małych eventów (do 300 uczestników) z darmowym pierwszym wydarzeniem nie generował konwersji — okazało się, że ten segment ma za mało patronatów medialnych (1-2 na event), żeby narzędzie miało sens. Wycofaliśmy ten plan i skupiliśmy się na eventach od 8 patronów wzwyż. Najdroższą porażką była próba cross-sellu do agencji eventowych pełnoobsługowych — inna persona użytkownika (account manager pracujący na 5 eventach jednocześnie), inny model cenowy, inny pricing per-seat zamiast per-event. Po dwóch miesiącach wycofaliśmy się i zaparkowaliśmy ten segment do osobnej linii produktu. Koszt tej lekcji: około sześciu tygodni pracy zespołu plus opportunity cost.

Metryki po 12 miesiącach

Trzy z tych liczb to dyscyplina scope’u, jedna to dystrybucja sieciowa. Skala bez rescue-mode’u w środku roku — bo nie było czego ratować, decyzje zapadały tygodniowo, a nie kwartalnie.

40 procent miesiąc do miesiąca jest realistyczne w pierwszych sześciu miesiącach, kiedy baza startowa jest niska — następnie stabilizuje się na 10-15 procent miesięcznie, co przy bazie 200 wydarzeń oznacza 20-30 nowych eventów miesięcznie. NPS 64 wśród event managerów jest wyjątkowo wysoki dla SaaS B2B (benchmark branżowy to 30-40) i interpretujemy go jako sygnał, że platforma realnie rozwiązuje problem, a nie tylko jest używana. ARR w przedziale „low 7-figures” oznacza poziom, który przy obecnej strukturze kosztów daje jednostkową rentowność — każde nowe wydarzenie ma dodatnią marżę od pierwszego użycia dzięki samoobsługowemu onboardingowi (na początku był asystowany, dziś 75 procent organizatorów uruchamia się bez kontaktu z supportem).

Lekcje dla innych venture builderów

Trzy obserwacje, które zabraliśmy z DailyHair do kolejnych projektów w ekosystemie.

Pierwsza: skin in the game zmienia decyzje na poziomie, który trudno przewidzieć przed wejściem w ten model. Kiedy jesteś udziałowcem, nie budujesz featurów na zapas, nie przyjmujesz zleceń pobocznych rozpraszających zespół, nie obiecujesz deadline’ów, których nie możesz dotrzymać. Dyscyplina scope’u wynika z samej struktury umowy, nie z dobrych intencji.

Druga: industry-specific wygrywa z generic zawsze, jeśli branża jest wystarczająco duża. Polski rynek eventów branżowych i konferencji to ponad 8 tysięcy aktywnych wydarzeń rocznie, z czego około 1500 obsługuje patronatów medialnych w skali wartej platformy. Jeśli obsłużysz 15 procent, masz 200+ klientów SaaS — to rozmiar, przy którym industry-specific produkt ma lepszą jednostkową ekonomikę niż generyczne narzędzie z dużą bazą, ale niskim ARPU. To samo równanie zadziała w każdej dużej branży wertikalnej: legaltech, automotive, medtech, real estate.

Trzecia, najtrudniejsza: MVP w 8 tygodniach to nie jest start, to jest filtr. Jeśli zespół nie jest w stanie dostarczyć użytkownikom testowej wersji w ciągu ośmiu tygodni, problem nie leży w czasie — leży w zakresie, w architekturze albo w zespole. Framework MVP w 8 tygodni nie jest obietnicą tempa; jest narzędziem weryfikacji, czy projekt ma w ogóle szansę na skalowanie.

Co dalej z DailyHair

Następne 18 miesięcy ma logikę, nie checklistę. Polski rynek eventów branżowych zbliża się do sufitu adresowalności przy obecnej propozycji wartości — 200+ klientów to już 13% udziału w niszy, a krzywa marginalna kosztu pozyskania będzie rosła, jeśli nie zmienimy żadnego z trzech wektorów. Stąd kolejność.

Ekspansja geograficzna jest pierwsza, bo unit economics DailyHair są mocne (jednostkowa marża dodatnia od pierwszego eventu), a rynek DACH ma 2,3× wyższe ARPU od polskiego przy tej samej strukturze patronatu medialnego. Q3 2026 — Niemcy i Austria, Q4 2026 — Czechy, Węgry, Rumunia. Discovery w terenie poprzedzi każde wejście, bo polski playbook nie jest transferowalny w skali 1:1: niemiecki rynek konferencji branżowych ma silniejszą obecność mediów wertikalnych (Heise, c’t, Computerwoche) i inny rytm publikacyjny niż polski.

Nowe segmenty — festiwale kulturalne i targi B2B — to extension istniejącej platformy bez zmiany core architektury. Festiwale ze względu na dłuższy cykl patronatu medialnego (3-6 miesięcy zamiast 4-8 tygodni) i większą wagę mediów regionalnych. Targi ze względu na moduł zarządzania stoiskami sponsorskimi, który dzieli 70% logiki z modułem patronatu medialnego. Obie ścieżki są tańsze niż wejście na nowy rynek geograficzny, ale dają mniejszy marginalny ARR.

Warstwa danych jako produkt — to lewar. Przy 200+ wydarzeniach mamy zanonimizowane dane o trendach rynku patronatu medialnego (średnie wartości pakietów per branża, deadline’y publikacyjne według typu medium, wskaźniki retencji partnerów medialnych pomiędzy edycjami). To aktyw, który przy odpowiednim opakowaniu produktowym staje się drugim strumieniem przychodu: raport branżowy dla agencji eventowych, benchmarki dla nowych organizatorów, dane referencyjne dla mediów wyceniających pakiety patronackie. Margin tego produktu byłby przyzwoity, bo dane już istnieją — koszt to dystrybucja i utrzymanie warstwy raportowej.

Te trzy wektory uruchamiamy równolegle, nie sekwencyjnie. Sequence to przywilej startup’ów z runwayem 36 miesięcy. My mamy P&L i konkurencję, która nie odpowiedziała jeszcze na nasz lead, ale odpowie w ciągu 12-18 miesięcy.

Masz produkt i szukasz partnera, nie wykonawcy?

Jeśli masz branżowe doświadczenie, problem wart rozwiązania i jesteś gotowy dzielić ryzyko z kompetentnym partnerem technologicznym zamiast wystawiać fakturę za godziny — rozmawiamy o venture buildingu. Opisz projekt w konfiguratorze albo napisz bezpośrednio na office@domoresoft.com z tematem „Venture building partnership”. Scoping trwa 2-4 tygodnie, pierwsza rozmowa jest wolna od opłat, ale nie od konkretów. Jeśli wolisz poznać model zanim się odezwiesz, przeczytaj jak Do More Soft stał się venture builderem i zajrzyj na stronę o nas.

FAQ

Czym jest venture building w software? Model partnerstwa, w którym zespół technologiczny obejmuje udziały w spółce produktowej w zamian za zredukowaną stawkę pokrywającą podstawowe koszty. Skin in the game zmienia każdą decyzję scope’u — bo każda godzina niepotrzebnej pracy zmniejsza wartość własnej inwestycji.

Ile trwa budowa SaaS MVP? 8 tygodni dla zakresu pojedynczego problemu z jasnym filtrem walidacji. To nie tempo, to filtr — jeśli zespół nie dostarcza w 8 tygodni, problem leży w zakresie, architekturze albo zespole.

Czym różni się software house od venture buildera? Software house optymalizuje pod zakres i budżet, odbiera fakturę i odchodzi. Venture builder optymalizuje pod retention, MRR i ARR, jest udziałowcem, zostaje na 5+ lat. Ta różnica filtruje 90% propozycji, które trafiają na nasze biurko.

Ile equity zachowujesz w partnerstwie venture-building? Większość — typowo 60-75% dla partnera branżowego, reszta dla zespołu technologicznego. Proporcje wynikają z fazy produktu, ryzyka technologicznego i wkładu operacyjnego. W DailyHair zredukowaliśmy stawkę o ~40% rynkowej wyceny w zamian za udziały.