Чому сеньйорська інженерна команда обіграє 100-особове агентство аутстафу на проєктах 0→1

Я сидів по обидва боки столу. Керував маркетинговим агентством послуг. Наймав і звільняв інженерних підрядників. Випускав продукти. І бачив, як розумні засновники спалювали шестизначні суми за три місяці на аутстаф-агентствах, які давали їм сім мідл-інженерів і нуль робочого софту.

Тож коли мене питають: «Нам найняти 50-особове агентство чи 5-особову сеньйорську команду?» — для раннього продукту чесна відповідь така: залежить від того, що ти насправді намагаєшся зробити. Здебільшого для 0→1 це маленька сеньйорська команда. Але не тому, що маленьке — це чеснота. А через те, як продуктова робота накопичується — або ні.

Приховане припущення всередині «більше людей = швидше»

Засновники просять хедкаунт, бо саме так виглядає їхня кеп-таблиця, і бо в їхньому попередньому корпоративному житті все винагороджувало масштаб. Проєкт відстає — кинь на нього людей. Це працювало, коли робота була тікетами. Це не працює, коли робота — рішення.

0→1 — це рішення. Чи має ця фіча існувати? Як її назвати? Де живе API? Хто відповідає за схему бази даних? Який план відкату? Кожне з цих питань — розвилка, і сеньйор-інженер відповідає на десять таких на день, часто навіть не помічаючи цього. Джуніор-інженер з агентства не відповідає на жодне — він чекає, поки хтось скаже, яку розвилку обрати.

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

Що сеньйорська команда реально робить у перший день

Коли ми починаємо білд, перші три дні — це не «підняти репозиторій». Це:

• Сперечатися про те, що таке продукт. Із засновником. У кімнаті. П’ять годин поспіль.
• Обрізати специфікацію, поки не залишаться лише несучі елементи.
• Обрати нудний стек, який дозволяє випуститися за тиждень.
• Побудувати найменшу версію найважливішого користувацького флоу, від і до, задеплоєну.

До п’ятого дня засновник клацає щось живе на реальному домені. До п’ятнадцятого — реальні користувачі відповідають на реальні питання всередині продукту. До тридцятого — працює білінг.

Де аутстаф-агентства реально виграють

Я не вдаю, що модель сеньйорської команди універсальна. Аутстаф-агентства виграють у трьох випадках:

1. У тебе вже є product-market fit і потрібна потужність виконання. Якщо специфікація зафіксована, архітектура визначена і треба просто клепати фічі пів року — аутстафінг цілком підійде.

2. Тобі потрібно закрити конкретну позицію під відому роль. Сеньйор Solidity-розробник на три місяці, спеціаліст із Salesforce для міграції. У хорошого агентства є лавка запасних.

3. Тобі потрібне географічне покриття чи комплаєнс, які інакше не отримати. Мультирегіональні розрахунки заробітної плати, SOC 2 due diligence постачальника.

Зверни увагу на спільну нитку: *ти вже знаєш, чого хочеш*. Чим далі ти від продуктової визначеності, тим гірше працює аутстафінг.

Жорстока економіка

Порахуймо на реальному сценарії. У тебе є $250K, щоб довести продукт до PMF за 6 місяців.

Варіант A — аутстаф-агентство, вісім інженерів по $85/год.

$85 × 160h × 8 = $108,800 на місяць. Через два місяці ти на нулі. У тебе дошка Jira з 240 закритими тікетами і продукт, який не працює повністю від і до, бо ніхто не відповідав за шар інтеграції.

Варіант B — сеньйорська команда з чотирьох, змішана ставка $140/год.

$140 × 160h × 4 = $89,600 на місяць. Ти отримуєш три місяці за $268,800 — трохи понад бюджет, але керовано. Результат: живий продукт із платними користувачами, підключений білінг, три тижні циклів зворотного зв’язку вбудовані всередину, і архітектурні рішення, які протримаються два роки.

Сеньйорська команда дорожча за годину і дешевша за результат.

Як реально купити сеньйорську інженерію

Якщо ти вирішив, що хочеш саме сеньйорську команду, ось як я купував би її на місці засновника:

1. Спершу заплати за платний скоупінг. Два тижні, фіксована ціна. На виході — реальна специфікація, реальна архітектурна діаграма й чесна оцінка термінів.

2. Наполягай на розмові з тими, хто реально писатиме код. Не з партнером. Не з акаунт-менеджером. З інженерами.

3. Зроби перший результат маленьким і придатним до випуску. Два тижні роботи. Якщо за два тижні не можуть запустити щось живе, шість місяців це не виправлять.

4. Май письмову операційну угоду. Код у твоєму репозиторії з першого дня. CI/CD на твоїх акаунтах. Ніяких «передамо все наприкінці».

5. Встанови kill switch. Перший місяць — пробний. Якщо до четвертого тижня команда нічого не випустила, обом краще розійтися.

Неочевидна перевага, про яку ніхто не згадує

Ось справжня причина, чому сеньйорські команди накопичуються: вони вчать тебе, як керувати інженерією, коли ти забираєш її in-house. Три місяці з людьми, які знають, як виглядає «добре» — і твій перший штатний найм після них успадковує робочу культуру, а не купу боргів. Аутстаф-агентство лишає тобі дошку Jira. Сеньйорська команда лишає тобі playbook.

Наостанок — незручна частина

Цей текст цілком упереджений. Я керую сеньйорською інженерною командою. Ми беремо за це відповідну ціну. Звісно, я вважаю, що ми — правильна відповідь для 0→1-продуктів.

Але ось у чому суть — я не кажу, що варто найняти саме *нас*. Я кажу, що якщо ти на етапі 0→1 і шукаєш «більше розробників» — ти шукаєш не той продукт. Сеньйорська інженерія для ранніх продуктів — це дисципліна, а не категорія постачальників. Чотириособова команда з твого кола довіри обіграє п’ятдесятиособове агентство на сейлз-дзвінку. Майже завжди.

Уперше опубліковано на mktrl.dev/blog.