Будівництво DailyHair — від нуля до 200 обслужених подій за 12 місяців

У II кварталі 2025-го, на конференції Cupra у Варшаві з 47 медіапартнерами, ми отримали мейл від координаторки о 22:47: „Учетверте цього тижня Forbes посуває дедлайн. Wyborcza хоче інший бриф, ніж TVN24. Маю це все в Excel на трьох вкладках, але о 6:00 завтра маю надіслати 47 окремих підсумувань і вже не знаю, хто на чому стоїть.” У вкладенні — скриншот таблиці, де рисками вона позначала дедлайни, узгоджені телефоном. Через дві години була галузева конференція, яку ми співорганізовували — перша, на якій ми побачили той самий pattern у трьох наступних менеджерок комунікації. Того ж тижня ми почали будувати DailyHair.

Число „47 медіапатронів” саме по собі не вражало. Воно було симптомом операційної архітектури, якої не обслуговує жоден загальний інструмент для подій. Менеджерка комунікації не організовувала захід — вона гасила пожежі між двома світами: організатором, що хоче максимуму видимості, і медіа, що хочуть максимуму вартості за свій патронат.

У DailyHair від початку зійшлися три умови, яких ми шукаємо в кожному партнерстві venture-building. Перша: експертка з 12 роками у PR подій і списком 30 знайомих організаторів, готових протестувати продукт — це не була гіпотеза, це була дистрибуція на старті. Друга: ринок 1500 польських конференцій на рік, що обслуговують медіапатронати, з яких 15% — це вже 200+ клієнтів SaaS. Третя, найважча: нульова терпимість партнерки до програмного забезпечення, що вимагає двогодинного onboardingu посеред event-спринту — що операційно означало, що кожна фіча мала запрацювати за 5 хвилин або не існувати. Ці три умови операційно виглядали як рідкісний момент, у якому ідея, дистрибуція і дисципліна scope’у — в одній парі рук.

Чому ми не побудували чергового Eventbrite

Eventbrite, Evenea, Konfeo — добрі для маси. Це прагматичні інструменти для організатора, який хоче „мати онлайн-квитки” і не диференціюватися нічим понад це. Але ринок, який нас цікавив — галузеві події та конференції з бюджетом від 200 тис. злотих угору, де медіапатронат і спонсорство становлять значну частину фінансування — має специфічні потреби, яких загальна квиткова платформа не адресує.

По-перше: управління медіапатронатами як першорядним об’єктом. Патронат — це не „квиток категорії FREE”. Це угода з медіа, в якій обидві сторони мають зобов’язання (публікація анонсу, пост у соцмедіа, банер на конференції в обмін на лого, згадку та пул квитків). Кожен патронат має свій бриф, свій пакет матеріалів, свої дедлайни, свої post-event-звіти. Бракувало інструменту, що розуміє цей двосторонній контракт нативно.

По-друге: пакети патронацькі. Головний медіапатрон плюс пресовий патрон плюс радіопатрон плюс інтернет-патрон — це не чотири окремі контракти, а одна подія з варіантним пакетом для кожного рівня. Eventbrite обслуговує це слабко — платформа примушує жорсткий каталог ролей, що не відповідає реальним ієрархіям медіапартнерства.

По-третє: правила медіа. „Wyborcza” публікує анонси лише за 21 день до події, „Forbes” вимагає ексклюзивного інтерв’ю з доповідачем, локальна радіостанція потребує готового спота у MP3. У загальному інструменті кожне медіа отримує той самий бриф. У реальному менеджменті патронатів кожен партнер має власний ритм, формат і чек-лист deliverables. Ми потребували системи, що розуміє ці правила нативно, а не обходить їх через коментарі у таблицях.

По-четверте: розрахунок вартості патронату в EAV (Equivalent Advertising Value), а не у квитках. Медіапатрон повертається до організатора, який дав йому повернення 4-6× у вигляді публікацій, експозиції на події і post-event-даних. Не до того, хто дав йому пул квитків. Розрахунок вартості — фундамент поновлення патронату. На практиці це означало іншу модель даних, ніж у типовій event-SaaS: медіа як першорядний об’єкт з ROI-історією, подія як контейнер.

Venture Builder vs. Software House — що обирають scale-up’и?

Вимір	Software House	Venture Builder
Модель розрахунку	Рахунок за години / scope	Знижений flat fee + equity у компанії
Горизонт рішень	До здачі проєкту	5+ років, спільний P&L
Оптимізація під	Обсяг і бюджет	Retention, MRR, ARR
Хто бере ризик продукту	Клієнт	Обидві сторони — співвласники
Рішення про фічу	„Клієнт просить, ми будуємо”	„Чи це рушить retention?”
Що дієсь після deploy	Рахунок, support hourly	Команда залишається — це її компанія
Профіль партнера	Будь-хто з бюджетом	Галузевий експерт + дистрибуція + масштаб

Scale-up’и з дистрибуцією на старті (список 30+ знайомих користувачів, пілотні контракти на конференціях, валідація ніші) обирають venture builder, бо дисципліна scope’у і спільний upside стискають 24 місяці до 12. Решта — software house, рахунок, ясна межа. Повний framework ми описали в послугах venture builder.

Модель: venture building, не проєкт на замовлення

Клієнтка прийшла з ідеєю, дванадцятьма роками операційного досвіду в PR і event-комунікації та списком 30 знайомих галузевих організаторів, які обіцяли протестувати продукт. Ми прийшли з технологією, досвідом будівництва і скейлінгу SaaS і бізнес-архітектурою, якої навчилися при 11 інших продуктах в екосистемі Do More Soft Venture Builder.

Ми могли оцінити проєкт як замовне програмне забезпечення — близько 380-420 тисяч злотих за MVP плюс утримання. Ми могли зробити це у форматі T&M з двомісячним буфером і звичайним рахунком. Ми могли запропонувати класичний fixed price з контрактними штрафами за затримки. Ми могли навіть відмовитися, бо масштаб event-ринку PL менший, ніж більшість ідей, що потрапляють до нас на стіл.

Натомість ми запропонували структуру компанії, у якій стали співвласниками, а наша винагорода за перші 12 місяців була зведена до покриття базових витрат команди. Різниця між ринковою оцінкою і реально виплаченою сумою стала нашою інвестицією у частки.

Це рішення, що змінює все. Software house оптимізує під обсяг проєкту і бюджет. Venture builder оптимізує під показники retention, MRR та ARR. Не будуєш фічей про запас, бо кожна непотрібна година зменшує цінність твоєї інвестиції. Не ігноруєш фідбек користувачів, бо це твої клієнти. Не йдеш після отримання рахунку — бо немає рахунку, є спільний P&L. Skin in the game — це не слоган, це інструмент дисципліни scope’у.

Фази будівництва — від ідеї до 200 подій

Цілий цикл — від першої розмови з клієнткою до 200 обслужених подій — зайняв 12 місяців. Ми поділили його на чотири розділені фази з ясними критеріями переходу між ними.

Фаза 1: Discovery (4 тижні)

Чотири тижні з організаторами і медіа, перш ніж упала перша лінійка коду. 22 інтерв’ю — з менеджерками комунікації галузевих конференцій, з редакторами розділів подій на порталах, з директорами маркетингу регіональних медіа. Кожне інтерв’ю — дві години спостереження workflow плюс година структурованих питань.

З цих 22 інтерв’ю випливло щось, чого ми б не припустили в жодному pre-discovery brainstormi: менеджерки комунікації не потребують „кращої event-платформи”. Вони потребують системи, що зніме з них роль живого API між 47 редакціями. Це одне спостереження визначило архітектуру — і вирізало з roadmapy три модулі, що раніше здавалися очевидними.

Результат був несподіваний в іншому вимірі. Три найбільші pain points не стосувалися ані самого квиткування, ані сторінки події. Першим була фрагментація каналів комунікації з патронами (мейл + Messenger + зовнішній Slack + WeTransfer + телефон). Другим — відсутність видимості статусу патронацьких матеріалів у реальному часі (організатор не знає, чи „Wyborcza” вже відправила анонс, чи він у редакційному буфері, чи редактор чекає на виправлене фото). Третім — відсутність твердих даних до розрахунку вартості патронату post-event (скільки людей з якого медіа дійшло, скільки публікацій з’явилося, який був сумарний reach vs ринкова вартість пакета).

Це відкриття визначило архітектуру продукту. DailyHair не мав бути „платформою для квитків” — мав бути операційною системою управління патронатами і комунікацією навколо події. Цей reframing зекономив нам три місяці роботи над обсягом, який не мав би значення для користувачів. Наш discovery process — фільтр, і цього разу він спрацював, як заплановано.

Фаза 2: MVP (8 тижнів)

Вісім тижнів на три речі: управління медіапатронатами (CRUD партнерів, пакети, дедлайни deliverables), центр матеріалів (брифи, ассети, чорнові версії, акцепти) і dashboard статусів (хто що, на коли, у якому статусі). Жодного квиткування. Жодного мобільного застосунку. Жодної аналітики поза базовими продуктовими метриками. Жодних інтеграцій із зовнішніми комунікаційними інструментами.

Вісім тижнів — це не темп, це фільтр. Якщо за цей час не вдається доставити користувачам щось, що вони можуть оцінити, проєкт має структурну проблему — або в обсязі, або в архітектурі, або в команді. У DailyHair обсяг помістився у вісім тижнів через те, що ми відрізали все, що не було необхідне для першого реального тесту з конференцією.

Stack обрали прагматично: React на фронтенді, Node.js з Express на бекенді, PostgreSQL як база даних, deploy на AWS ECS з S3 для зберігання патронацьких ассетів (логотипи, фото, банери, аудіофайли для радіоспотів). Жодних технологічних експериментів, жодного overengineeringu. Метою було досягти першого користувача, а не побудувати платформу на десять років.

Фаза 3: Pilot (3 місяці)

Вісім галузевих конференцій у першому кварталі 2025 року — від камеральних tech meetups у Кракові (200-400 учасників) до двох великих маркетингових конференцій у Варшаві (1500-2000 учасників), серед них згадана конференція Cupra з 47 медіапатронами. Кожна подія з безпосереднім onboardingiem, який особисто проводила співзасновниця продукту. Feedback loop 48-годинний — кожна повідомлена увага отримувала відповідь (навіть якщо звучала „цього не зробимо”) упродовж двох робочих днів, а одна на п’ять потрапляла до backlogu з пріоритетом до впровадження упродовж тижня.

Pilot виявив три речі, яких не передбачили б через жодну кількість discovery. Перша: менеджерки комунікації не хочуть логуватися у платформу для акцепту матеріалів — хочуть затверджувати через лінк у мейлі, без облікового запису. Це перевернуло наші припущення UX і змусило спроєктувати „magic-link approval flow” для патронів. Друга: організатори хочуть бачити сумарне EAV (Equivalent Advertising Value) усіх патронатів на поточно, не лише у post-event-звіті — бо це аргумент для комерційних спонсорів до збільшення контракту. Третя: редактори в медіа вимагають від організатора готових „press kits” упродовж 24 годин від підтвердження патронату — попередня версія MVP не мала цього flow, ми додали у третьому спринті пілоту.

Три місяці пілоту — це була найцінніша інвестиція в усьому проєкті. Без неї ми б скейлили продукт, що не відповідає реальним потребам користувачів.

Фаза 4: Скейлінг (6 місяців)

З восьми пілотних подій до двохсот обслужених. У цій фазі ми запустили мобільний застосунок у Flutter (одна codebase на iOS і Android) для onsite-event-менеджерів, інтеграцію Google Calendar та Outlook для синхронізації патронацьких дедлайнів, автоматичні post-event-звіти у PDF для кожного патрона і інтеграцію з платформами медіамоніторингу (Press-Service, Newspoint) для автоматичного підрахунку публікацій. Зростання відбувалося у двох каналах: word-of-mouth між організаторами (в середньому кожна обслужена подія порекомендувала 1,7 чергового організатора у першому кварталі після події) і referral program серед менеджерок комунікації (менеджерка, що змінювала роботодавця, забирала з собою досвід DailyHair і природно промувала платформу у нового організатора).

Упродовж шести місяців скейлінгу ми не витратили злотого на платну рекламу. ROI з word-of-mouth був настільки високим, що будь-яка витрата на paid marketing була б субоптимальною щодо інвестиції в якість onboardingu і швидкість відповіді supportu. Це рішення вимагало дисципліни — тиск „почнімо рекламувати на LinkedIn” повертався щомісяця — але математика його не обґрунтовувала.

Технологія як важіль, не мета

Tech stack DailyHair — це свідомо консервативні вибори. React, Node.js та PostgreSQL — це комбінація, у якій команда має найбільше експертизи, а екосистема бібліотек та інструментів — найглибша. Ми не шукали переваги у технологічному шарі — ми шукали переваги в темпі поставки і якості UX. Той самий decision framework ми застосували в Cupra mycarapp, де технологічний шар мав бути невидимим, а продукт — вимірюваний retention.

Magic-link approval (замість повного логіну для патронів) — це рішення, що усунуло найбільше тертя в адопції серед медіа. Редактор отримує лінк у мейлі, клікає, акцептує матеріал або відмовляє з коментарем — готово. Ми зекономили в такий спосіб щонайменше три місяці роботи над системою ролей і прав, а одночасно підняли response патронів з ~40 відсотків до понад 80 відсотків у першому кварталі.

Flutter замість нативних застосунків iOS і Android — це рішення, оперте на математиці: одна codebase, одна mobile-команда, один темп ітерацій. Втрачаємо близько 15 відсотків нативної досконалості UI, здобуваємо двократно швидший цикл розробки і двократно нижчу вартість утримання. У фазі зростання 40 відсотків місячно темп важливіший, ніж нативна досконалість.

AWS S3 для патронацьких ассетів — це очевидність: storage без infra ownership, вбудоване CDN (CloudFront), маргінальна вартість per event. Той самий аргумент: не будуй інфраструктури, якої не мусиш будувати. Детальну логіку добору stacku ми описали в контексті замовного програмного забезпечення — це той самий decision framework, який ми застосовуємо у кожному проєкті venture buildingu.

Перший рік — що працювало, що ні

Брутально чесний рахунок за 12 місяців.

Що працювало. Word-of-mouth між організаторами виявився значно сильнішим каналом, ніж ми припускали — event-індустрія густо змережена, менеджерки комунікації знаються особисто, а рекомендація від знайомого організатора важить більше, ніж case study і demo разом узяті. Центр матеріалів з magic-link approval — фіча, якої конкуренція не мала взагалі — став головним аргументом продажу; понад 70 відсотків організаторів визнали в анкеті після першого event’у, що саме ця функціональність переважила про рішення вибору DailyHair. EAV post-event-звіти полюбили директори маркетингу — виявилося, що вони задовольняють потребу твердого доказу вартості медіапатронату, якого не дає жоден інший інструмент (Excel рахований вручну після event’у нікого не переконує).

Що не працювало. Перша версія повідомлень email до патронів мала open rate 24 відсотки — багато нижче B2B-benchmarku. Після аналізу виявилося, що template виглядав як transactional notification з SaaS-системи, а не як особисте повідомлення від менеджерки комунікації. Ми перепроєктували шаблони у формат „personal email з лінком”, open rate скочив до 62 відсотків. Перший try-and-buy для малих event’ів (до 300 учасників) з безкоштовним першим заходом не генерував конверсії — виявилося, що цей сегмент має замало медіапатронів (1-2 на event), щоб інструмент мав сенс. Ми відкликали цей план і зосередилися на event’ах від 8 патронів вгору. Найдорожчою поразкою був cross-sell до агенцій event’ових повного обслуговування — інша user persona (account manager, що працює на 5 event’ах одночасно), інша модель ціни, per-seat pricing замість per-event. Через два місяці ми відступили і запаркували цей сегмент до окремої лінії продукту. Вартість цієї лекції: близько шести тижнів роботи команди плюс opportunity cost.

Метрики після 12 місяців

Три з цих чисел — це дисципліна scope’у, одне — мережева дистрибуція. Масштаб без rescue-mode’у посеред року — бо не було чого рятувати, рішення западали щотижня, а не щокварталу.

40 відсотків місяць до місяця реалістично у перші шість місяців, коли стартова база низька — далі стабілізується на 10-15 відсотках місячно, що при базі 200 подій означає 20-30 нових event’ів на місяць. NPS 64 серед event manager’ів — винятково високий для B2B SaaS (галузевий benchmark — 30-40), і ми інтерпретуємо його як сигнал, що платформа реально розв’язує проблему, а не лише використовується. ARR у діапазоні „low 7-figures” означає рівень, що при поточній структурі витрат дає одиничну рентабельність — кожна нова подія має додатну маржу від першого використання завдяки самообслуговуючому onboardingu (на початку був асистований, сьогодні 75 відсотків організаторів запускаються без контакту з supportom).

Уроки для інших venture builder’ів

Три спостереження, які ми взяли з DailyHair до наступних проєктів в екосистемі.

Перше: skin in the game змінює рішення на рівні, який важко передбачити перед входженням у цю модель. Коли ти власник часток, не будуєш фічей про запас, не приймаєш бічних замовлень, що відволікають команду, не обіцяєш дедлайнів, яких не можеш дотримати. Дисципліна scope’у випливає з самої структури угоди, не з добрих намірів.

Друге: industry-specific виграє з generic завжди, якщо галузь достатньо велика. Польський ринок галузевих подій і конференцій — це понад 8 тисяч активних подій на рік, з яких близько 1500 обслуговують медіапатронати в масштабі, вартому платформи. Якщо обслуговуєш 15 відсотків, маєш 200+ клієнтів SaaS — це розмір, при якому industry-specific продукт має кращу одиничну економіку, ніж загальний інструмент з великою базою, але низьким ARPU. Те ж рівняння спрацює у кожній великій вертикальній галузі: legaltech, automotive, medtech, real estate.

Третє, найважче: MVP за 8 тижнів — це не старт, це фільтр. Якщо команда не в змозі доставити користувачам тестову версію упродовж восьми тижнів, проблема не лежить у часі — лежить в обсязі, в архітектурі або в команді. Framework MVP за 8 тижнів — це не обіцянка темпу; це інструмент верифікації, чи проєкт взагалі має шанс на скейлінг.

Що далі з DailyHair

Наступні 18 місяців мають логіку, не чек-лист. Польський ринок галузевих подій наближається до стелі адресовності при поточній value proposition — 200+ клієнтів це вже 13% частки в ніші, а маргінальна крива витрат пошуку клієнта зростатиме, якщо ми не змінимо жодного з трьох векторів. Звідси послідовність.

Географічна експансія — перша, бо unit economics DailyHair потужні (одинична маржа додатна від першої події), а ринок DACH має 2,3× вище ARPU від польського при тій самій структурі медіапатронату. Q3 2026 — Німеччина і Австрія, Q4 2026 — Чехія, Угорщина, Румунія. Discovery в полі передуватиме кожному входу, бо польський playbook не транспортується в масштабі 1:1: німецький ринок галузевих конференцій має сильнішу присутність вертикальних медіа (Heise, c’t, Computerwoche) і інший публікаційний ритм, ніж польський.

Нові сегменти — культурні фестивалі і B2B-виставки — це extension наявної платформи без зміни core архітектури. Фестивалі — через довший цикл медіапатронату (3-6 місяців замість 4-8 тижнів) і більшу вагу регіональних медіа. Виставки — через модуль управління спонсорськими стендами, що ділить 70% логіки з модулем медіапатронату. Обидві стежки дешевші, ніж вхід на новий географічний ринок, але дають менший маргінальний ARR.

Шар даних як продукт — це важіль. При 200+ подіях ми маємо анонімізовані дані про тренди ринку медіапатронату (середні вартості пакетів per галузь, дедлайни публікацій згідно з типом медіа, показники retention медіапартнерів між редакціями). Це актив, який при відповідному продуктовому пакуванні стає другим потоком прибутку: галузевий звіт для event-агенцій, benchmarks для нових організаторів, референсні дані для медіа, що оцінюють патронацькі пакети. Маржа цього продукту була б пристойною, бо дані вже існують — вартість це дистрибуція і утримання звітного шару.

Ці три вектори запускаємо паралельно, не послідовно. Sequence — це привілей стартапів з runway 36 місяців. Ми маємо P&L і конкурента, що ще не відповів на наш lead, але відповість упродовж 12-18 місяців.

Маєш продукт і шукаєш партнера, не виконавця?

Якщо маєш галузевий досвід, проблему, варту розв’язання, і готовий ділити ризик з компетентним технологічним партнером замість виставлення рахунку за години — поговорімо про venture building. Опиши проєкт у конфігураторі або напиши безпосередньо на office@domoresoft.com з темою „Venture building partnership”. Scoping триває 2-4 тижні, перша розмова — без оплат, але не без конкретики. Якщо хочеш зрозуміти модель перед тим, як зголоситися, прочитай як Do More Soft став venture builder’ом і подивись на сторінку про нас.

FAQ

Що таке venture building у software? Модель партнерства, в якій технологічна команда отримує частки у продуктовій компанії в обмін на знижену ставку, що покриває базові витрати. Skin in the game змінює кожне рішення scope’у — бо кожна година непотрібної роботи зменшує цінність власної інвестиції.

Скільки триває будівництво SaaS MVP? 8 тижнів для обсягу одного проблемного домену з ясним фільтром валідації. Це не темп, це фільтр — якщо команда не доставляє за 8 тижнів, проблема лежить у scope, в архітектурі або в команді.

Чим відрізняється software house від venture builder’а? Software house оптимізує під обсяг і бюджет, забирає рахунок і йде. Venture builder оптимізує під retention, MRR і ARR, він власник часток, залишається на 5+ років. Ця різниця відсіює 90% пропозицій, що потрапляють до нас на стіл.

Скільки equity зберігаєш у партнерстві venture-building? Більшість — типово 60-75% для галузевого партнера, решта для технологічної команди. Пропорції випливають з фази продукту, технологічного ризику і операційного внеску. У DailyHair ми знизили ставку на ~40% ринкової оцінки в обмін на частки.