[Зміст]Показати зміст
У 2016 році, з Кшиштофом П., дилером Cupra з Кракова, на аркуші паперу: VIN-tracker за 200k PLN в Excel. Так почалася Do More Soft. Сьогодні маємо 12 власних продуктів, команду з понад десятка спеціалістів і більше 80 реалізованих проєктів. Шлях не був лінійним, і саме тому варто його розповісти.
Початки: automotive як школа виживання
Перший серйозний проєкт — система для автодилера. Інтеграція з фабрикою, відстеження VIN-ів, калькулятор фінансування. Automotive навчив нас двох речей: складні бізнес-процеси вимагають глибокого розуміння домену, а клієнти не хочуть «програмного забезпечення». Хочуть розв’язання своєї проблеми. Цей урок визначає нас досі.
У перші 18 місяців ми доводили проєкти до кінця, бракувало грошей, не знали, що клієнт робить із кодом. Відчувалося як поразка, хоча рахунки показували успіх. Модель лінійна, передбачувана, але обмежена. Нам бракувало відчуття співвласності над тим, що будуємо.
Точка перелому: рішення про власні продукти
У 2020 році я мав дилему. Наймати девів і продавати години чи побудувати продукт. Вибір зробився сам, коли ми програли тендер на 300k з мінімальною різницею. Тоді почали будувати власні продукти. Не тому, що не мали клієнтів. Тому, що бачили повторювані проблеми у багатьох компаній і знали, що вміємо вирішити їх системно.
Це був ризикований крок. Будівництво власних продуктів вимагає інвестицій часу, грошей та енергії, які могли б піти на комерційні проєкти. Але дало нам те, чого не дасть жоден замовний проєкт: skin in the game. Коли будуєш продукт, який сам мусиш підтримувати й розвивати, ухвалюєш інші архітектурні рішення, ніж коли віддаєш код і йдеш.
Чим software house відрізняється від venture builder?
Класичний software house має прихований конфлікт інтересів: чим довше триває проєкт, тим більше заробляє. Venture builder заробляє на успіху продукту, а не на годинах, спалених на проєкті. Це фундаментальна різниця у стимулах, що переноситься на кожне рішення — від вибору технології до обсягу MVP.
Коли будуємо продукт за власний рахунок, мусимо бути безжально прагматичними. Не дозволимо собі overengineering, бо це наші гроші. Не проігноруємо фідбек користувачів, бо це наші клієнти. Не побудуємо і не покинемо, бо це наш P&L. Дисципліна переноситься на проєкти для клієнтів. Ми навчилися мислити як власники, а не як субпідрядники.
Venture Builder vs. Software House: фундаментальні відмінності
| Вимір | Software House | Venture Builder |
|---|---|---|
| Модель доходу | Рахунки за години | Співвласність продукту, equity, success fee |
| Горизонт рішень | До здачі проєкту | 3-5 років продакшн-операції |
| Архітектура | Під демо й приймання | Під підтримку й масштабування |
| Естімейти | Оптимістичні (виграти тендер) | Реалістичні (вже подібне будували) |
| Рішення щодо scope | «Клієнт хоче, робимо» | «MVP чи nice-to-have?» |
| Skin in the game | Немає після деплойменту | Три роки після деплойменту |
12 продуктів — що будуємо і чому
MoreSales народився з втоми. MyCarApp — бо дилерів навчилися у Cupra. OpenEZD — бо публічна адміністрація особисто мене виснажувала. Так народжується більшість продуктів в екосистемі: не з research deck’у, а з болю, який хтось із нас побачив зблизька.
Екосистема охоплює MoreSales і MoreCRM (CRM/ERP), галузеві платформи — MyCarApp для automotive, DailyHair для beauty, CalMedic для medtech, Kwadracik для нерухомості — документообіг (OpenEZD, MoreGenerator), AI і контент (Textio), а також інструменти MoreNFC, MoreMobile і GetMeCon.
DailyHair — добрий приклад venture building на практиці. Галузь beauty потребувала системи бронювання, яка не є генеричним Booksy. Системи, що розуміє специфіку перукарень і барбершопів. Ми побудували її, впровадили в пілотних салонах, ітерували на основі фідбеку і масштабуємо як незалежний продукт.
Що означає skin in the game у software-партнерствах?
Клієнт, що приходить до software house, отримує команду, яка писала код. Клієнт, що приходить до venture builder, отримує команду, що будувала, запускала, підтримувала й масштабувала власні продукти. Різниця — в операційному досвіді. Знаємо, що діється після деплойменту, бо живемо з того, що впровадили.
Конкретно це означає: реалістичні естімейти (будували подібні системи за власний рахунок, знаємо, скільки що триває), архітектуру під підтримку замість під демо (самі підтримуємо продукти роками) і прагматичні рішення щодо scope (знаємо, що є MVP, а що nice-to-have, бо багаторазово ухвалювали ті самі рішення для себе).
Уроки з десятиліття будівництва
Перший урок: досконалість — ворог доставки. Краще випустити міцні 80%, ніж досконалі 100%, які ніколи не вийдуть на продакшн. Другий: технологія — це важіль, а не мета. Клієнта не обходить, чи використовуєш React, чи Vue. Обходить його, чи система вирішує його проблему. Третій: команда важливіша за стек. Хороший програміст у посередній технології дає кращі результати, ніж посередній у найновішій.
Найскладніший урок: кажи «ні». У 2023 клієнт із бюджетом 500k на SaaS для логістики. Я сказав «ні». Не маємо domain expert, не маємо референцій. Погано обраний проєкт коштує більше, ніж відсутність проєкту. Складний урок для компанії, що хоче рости, і фундаментальний для компанії, що хоче рости розумно.
Візія: що далі
Не хочемо бути HR-ом для software. Хочемо бути операторами продуктів, які знають, що станеться на третьому році, бо ми там уже були. Модель: venture builder, що ділить ризик і прибуток із партнерами, замість виставляти рахунки за години.
Протягом найближчих двох років хочемо розвинути екосистему до 15-18 продуктів, сильніше увійти на ринки DACH і CEE, та побудувати технологічну платформу, що дозволить швидше запускати нові продукти — зі спільним шаром автентифікації, платежів, аналітики та інфраструктури. Не будуємо software house. Будуємо машину для створення цифрової цінності.
FAQ
Як модель venture builder відрізняється від класичної розробки?
Класична розробка — це рахунки за години. Venture builder заробляє на успіху продукту — через співвласність, equity або success fee. Це змінює кожне рішення: від стеку до обсягу MVP, від архітектури до SLA.
Чому venture builder-и ухвалюють кращі архітектурні рішення?
Бо самі живуть із наслідками. Software house віддає код і виставляє рахунок. Venture builder підтримує продукт три роки після впровадження, тому не побудує того, чого не хоче плекати. Рішення прагматичні, а не показові.
Чи Do More Soft працює також у моделі замовлення?
Так, але вибірково. Беремо проєкти, у яких можемо застосувати know-how із власних продуктів — automotive, beauty, medtech, GovTech, нерухомість. Проєкти «будь-що, аби програміст» відкидаємо.