Стартап-команда на ранньому етапі — це не група людей із красивими резюме. Це мінімальна конфігурація, здатна перевірити гіпотезу, зібрати прототип і отримати перші сигнали від ринку. Нижче — практичний погляд на те, кого шукати, як залучати і як не розвалити команду в перші місяці.
Коли потрібна команда, а коли достатньо одного або двох
Поширена помилка — збирати команду до того, як зрозуміла суть проблеми. Якщо ви ще не сформулювали, чия саме проблема, хто платить і навіщо вашому продукту потрібна Solana, додаткові люди лише ускладнять координацію.
Однієї людини достатньо, коли:
- ви технічний фаундер і можете самі зібрати робочий прототип;
- головне завдання нині — валідація: розмови з потенційними користувачами, перевірка попиту, а не написання коду;
- продукт ще не вийшов за межі «ідея на папері».
Двох людей достатньо, коли:
- один фокусується на продукті та технологіях, другий — на користувачах, ринку та бізнес-моделі;
- прототип уже існує, потрібні перші користувачі та зворотний зв'язок;
- ви чітко поділили зони відповідальності і не перетинаєтеся в щоденних рішеннях.
Команда з трьох і більше має сенс, коли прототип показав попит, є перші користувачі, а вузьке місце — у швидкості розробки чи виході на новий сегмент. Розширювати команду «на всякий випадок» або «щоб виглядати солідніше перед інвесторами» — марно і дорого.
Ключові ролі на ранньому етапі
Розробник, продуктовий менеджер, дизайнер
Ці три ролі формують кістяк, який здатен створити робочий продукт. Але на ранньому етапі вони не обов'язково мають бути трьома різними людьми.
Розробник — людина, яка може реалізувати продукт технічно. У контексті Solana це означає розуміння Rust або TypeScript, знайомство з Anchor (фреймворк для написання смарт-контрактів на Solana), вміння працювати з RPC-вузлами (сервери для взаємодії з блокчейном). Важливо: розробник має розуміти, чому саме Solana, а не просто «хоче спробувати блокчейн».
Продуктовий менеджер — формулює, що саме будуємо і для кого. Відповідає на питання: чия проблема, як ми дізнаємося, що вирішили її, які метрики покажуть успіх. Часто на ранньому етапі цю роль виконує фаундер.
Дизайнер — не просто «малює інтерфейс», а продумує, як користувач взаємодіє з продуктом. У Web3 це особливо важливо: підключення гаманця, підписання транзакцій, розуміння того, що відбувається з коштами — усе це має бути зрозумілим без технічної освіти.
Реалістична конфігурація: технічний фаундер (розробник + частково продакт) плюс одна людина з фокусом на ринок і користувачів. Дизайнера залучайте пізніше або на контрактній основі для конкретного прототипу.
Чи потрібен маркетолог чи бізнес-розробник одразу
Ні, якщо у вас ще немає продукту, яким можна зацікавити користувача. Маркетинг без продукту — це генерація трафіку в нікуди. Бізнес-розробник потрібен, коли є щось конкретне для продажу або партнерства.
Виняток: якщо ваш продукт орієнтований на B2B-клієнтів у специфічній ніші (наприклад, інфраструктура для інституційних інвесторів у RWA — токенізованих реальних активах), і ви знаєте конкретних людей, з якими треба поговорити вже зараз. Тоді людина з контактами і досвідом у цій ніші може бути корисною. Але це скоріше роль «доменного експерта», ніж класичного бізнес-розробника.
Як залучити людей на ранньому етапі
Equity, гроші, спільна місія
На етапі, коли грошей немає або мало, є три реальні важелі:
Частка в компанії (equity). Працює, якщо людина вже довіряє вам або має попередній позитивний досвід співпраці. Не роздавайте рівні частки всім підряд — це гарантований конфлікт при прийнятті рішень. Типова помилка: «ми всі по 25%, бо всі однаково важливі». Ніхто не однаково важливий на етапі, коли ще немає продукту.
Гроші. Навіть мінімальна оплата показує, що ви ставитеся до співпраці серйозно. Якщо не можете платити повну ставку — пропонуйте контрактну роботу на конкретний результат: «нам потрібен прототип цієї функції, ось сума, ось терміни». Це чесніше, ніж «працюй безкоштовно, потім буде частка».
Спільна місія. Найслабший важіль, якщо використовувати його самостійно. «Ми змінимо світ децентралізації» не оплатить оренду. Але як додаток до equity або грошей — працює: людина має вірити в те, що робить, а не просто торгувати своїм часом.
Чому обіцянки «коли отримаємо інвестиції» не працюють
Тому що це не пропозиція — це лотерея. Ви фактично кажете: «працюй безкоштовно, а якщо нам пощастить — заплатимо заднім числом». Досвідчені люди на це не ведуть. Ті, хто ведуть — зазвичай не ті, кого ви хотіли б у команді.
Що замість цього:
- чесно скажіть, скільки ви можете заплатити зараз;
- якщо це equity — запропонуйте конкретний відсоток із чіткими умовами вестингу (період, протягом якого людина заробляє свої частки) і кліфом (час до початку нарахування часток);
- покажіть прогрес: навіть мінімальний прототип або результати інтерв'ю з користувачами краще, ніж «ми плануємо».
Розподіл відповідальності та комунікація
Інструменти, ритм зустрічей, прийняття рішень
На етапі двох-трьох людей не потрібна складна інфраструктура. Але без базових правил комунікація перетвориться на хаос.
Інструменти. Одне місце для завдань (Notion, Linear, подібне), один канал для оперативного спілкування (Telegram, Discord), один репозиторій для коду. Не розпорошуйте інформацію по п'яти сервісах — через місяць ніхто не знайде рішення, прийняті два тижні тому.
Ритм зустрічей. Раз на тиждень — синхронізація: що зроблено, що блокує, що планується. Не перетворюйте це на годинну доповідь — 30 хвилин достатньо. Якщо потрібні довші обговорення — проводьте їх окремо, з тими, хто безпосередньо залучений.
Прийняття рішень. Визначте однієї людини, яка приймає фінальне рішення в кожній сфері: технічні рішення — розробник, продуктові — продакт-менеджер. Спільне голосування працює погано: воно призводить до компромісних рішень, які влаштовують усіх наполовину і не працюють повністю.
Чітко фіксуйте рішення письмово. Навіть якщо ви домовилися голосом — напишіть один речення у загальному каналі: «Погодили: робимо варіант А, причини такі-то». Це уникне ситуацій «а я думав, ми домовилися інакше».
Як працювати з віддаленою командою
Часові зони, асинхронна комунікація, довіра
У Web3-стартапах віддалена робота — норма, а не виняток. Solana-екосистема глобальна, і ваш розробник може бути в Києві, дизайнер — у Лісабоні, а користувачі, з якими ви спілкуєтеся, — у Сінгапурі.
Часові зони. Якщо різниця перевищує 4–5 годин — спільні синхронізації стануть проблемою. Визначте вікно перекриття (наприклад, 2–3 години, коли всі онлайн) і використовуйте його лише для того, що дійсно вимагає живого обговорення. Все інше — асинхронно.
Асинхронна комунікація. Правило просте: якщо ви пишете повідомлення, воно має містити достатньо контексту, щоб людина могла зреагувати без додаткових уточнень. Не «подивись це, що думаєш?», а «подивись цей API-метод, мені здається, він підходить для нашої завдання з X, ось чому. Дай знати, чи згоден, або запропонуй альтернативу».
Довіра. Віддалена робота без довіри перетворюється на мікроменеджмент: «де ти? що робиш? чому не відповідаєш?». Це вбиває мотивацію за тижні. Довіра будується на результатах, а не на онлайн-статусі. Якщо людина виконує завдання в термін і якістю — не важливо, о котрій вона це зробила.
Практичний крок: домовтеся про формат звітності. Наприклад, коротке письмове оновлення раз на день або раз на два дні: що зробив, що планую, що блокує. Це замінює відчуття контролю без токсичного мікроменеджменту.
Типові проблеми перших команд
Розмиття відповідальності. Коли всі роблять усе — ніхто не відповідає ні за що. Якщо двоє людей «обоє займаються продуктом», рано чи пізно вони зроблять протилежні речі або просто чекатимуть, поки інший почне першим. Рішення: у кожної завдання є одна людина, яка відповідає за результат.
Розбіжність очікувань щодо залученості. Один працює над стартапом повний день, інший — «по вечорах і вихідних». Через місяць перший обурений, другий не розуміє претензій. Рішення: обговорити і зафіксувати очікувану кількість годин на тиждень до початку співпраці.
Конфлікти через рівні частки. Коли у всіх по 25% і немає лідера, будь-яке рішення перетворюється на переговори. Рішення: одна людина має більшу частку і фінальне слово. Це не означає диктатуру — це означає, що хтось бере на себе відповідальність.
Залишення «мертвих душ». Людина приєдналася, отримала частку, але через місяць втратила інтерес або не виходить на зв'язок. Без вестингу і кліфу ця людина назавжди залишається співвласником вашої компанії. Рішення: завжди використовуйте вестинг з кліфом (типово: 3–6 місяців кліф, потім щомісячний вестинг протягом 2–4 років). Якщо людина йде до закінчення кліфу — не отримує нічого.
Технологічний романтизм. Хтось у команді хоче використовувати Solana, бо це «круто і модно», а не тому, що продукт функціонально цього потребує. Якщо ваш продукт — це дошка оголошень, де блокчейн не додає жодної користі користувачу, не додавайте його лише тому, що команда хоче працювати з Web3. Це прямий шлях до продукту, який ніхто не використовуватиме.
Формування команди — не одноразова подія, а процес. На етапі прототипу вам потрібні одна або дві людини, які можуть швидко перевіряти гіпотези. Коли з'являться перші користувачі і зрозумілі вузькі місця — тоді розширюйте. Не раніше.