Питання «продукт чи аутсорс» майже завжди починають із грошей, і на порталі є чим на нього відповісти: зарплатний звіт рахує медіани по типах компаній із сирих анкет DOU. Але сама цифра — найменш корисна частина відповіді, бо вона нічого не каже про те, що ви робитимете в понеділок вранці. Нижче — з чого ця різниця складається в коді й у щоденній роботі, і як перевірити конкретний оферт замість того, щоб порівнювати себе з медіаною.
Цифра, з якої всі починають, і що в ній насправді
У хвилі «червень 2026» медіана продуктової компанії $4 000, аутстафу $3 700, сервісної (аутсорс) $2 900. На грейді Senior розрив стискається: $4 500 проти $4 100 і $3 500. Продуктових анкет 260 із 457, аутсорсних 89.
Три речі, які з цих чисел не випливають.
Медіана — це зріз популяції, а не прайс на трансфер. У продуктових компаніях більша частка Senior і Lead, більша частка людей із Upper-Intermediate і вище, більша частка тих, хто працює на закордонного замовника напряму. Розрив у $1 100 по ринку — це сума грейду, англійської й географії. На однаковому грейді він менший: $1 000 на Senior.
Медіана нічого не каже про вашу вилку. У звіті є квартилі, і коридор p25–p75 усередині кожного типу компанії ширший за розрив між типами. Верхня третина аутсорсу заробляє більше за нижню третину продукту. Порівнювати треба свою суму з фільтром по своєму грейду й типу компанії, а не з медіаною ринку.
Ярлик у вакансії — не характеристика інженерії. «Продуктова компанія» може означати один монолітний застосунок, який ніхто не оновлював три роки, а «аутсорс» — команду, що веде клієнтський продукт пʼятий рік поспіль і відповідає за його прод. Далі — про ознаки, які реально відрізняються, і жодна з них не пишеться в описі вакансії.
Горизонт життя коду: до здачі чи назавжди
Це головна технічна відмінність, з якої випливають майже всі інші. В аутсорсі горизонт вашого коду — дата здачі плюс гарантійний період. У продукті ви зустрічаєтесь із власним кодом через два роки, коли забули, чому там саме так.
Найпростіший наслідок — хто обирає версію PHP і фреймворку. В аутсорсі її обирає інфраструктура замовника: якщо в них PHP 8.1, ви пишете під 8.1, навіть якщо локально у вас 8.4. У composer.json це фіксують явно, щоб composer не притягнув пакет, який на проді не запуститься:
{
"config": {
"platform": { "php": "8.1.0" }
}
}
І далі ви щодня не використовуєте те, що вже вийшло:
// PHP 8.1: незмінність поля доводиться захищати вручну — приватне поле плюс геттер
final class Money
{
public function __construct(private int $amountMinor) {}
public function amountMinor(): int
{
return $this->amountMinor;
}
}
// PHP 8.4, версію обирає команда: асиметрична видимість робить те саме без геттера
final class Money
{
public function __construct(public private(set) int $amountMinor) {}
}
Різниця тут не в красі. Версія платформи визначає, які інструменти вам доступні для вирішення реальних задач, і в аутсорсі ви цю змінну не контролюєте — оновлення PHP чи мажорної версії фреймворку це окремий проданий обсяг робіт, а не рішення команди.
Другий наслідок — чи можна видаляти код. У продукті застарілий метод має дату смерті, бо всі виклики ваші:
final class InvoiceService
{
/** @deprecated Використовуйте issueInvoice(); прибрати після міграції останніх викликів. */
public function create(int $orderId): Invoice
{
trigger_error(__METHOD__.'() is deprecated, use issueInvoice()', E_USER_DEPRECATED);
return $this->issueInvoice($orderId);
}
}
Такий шим у продукті живе один-два релізи: ви бачите деприкейти в логах, дочищаєте виклики й видаляєте метод. В аутсорсі виклик може бути в коді замовника або іншого підрядника, а видалення — це зміна обсягу робіт, яку ніхто не замовляв. Тому сумісність накопичується шарами, і через три роки половина класу — це шляхи для випадків, яких уже не існує. Це не недбалість команди, це прямий наслідок того, хто володіє кодом і хто платить за прибирання.
Що вважається успіхом, і чого це вас навчить
В аутсорсі критерій успіху зовнішній і формальний: критерії приймання виконані, у строк, у межах оцінки. Це тренує рідкісні речі — оцінювати обсяг і не помилятись у два рази, торгуватись за скоуп, швидко занурюватись у чужу кодову базу, працювати з легасі, якого ви не писали, і документувати так, щоб передати. За три роки ви побачите пʼять різних проєктів, три версії фреймворку й два способи робити те саме.
У продукті критерій успіху — те, що сталося після релізу. Це тренує інше: ви живете з наслідками, чергуєте, розбираєте інциденти, робите бекфіли на накопичених даних, змінюєте схему під живим трафіком і плануєте оновлення платформи. За три роки ви побачите одну кодову базу, але в динаміці — включно з тим, як ваші рішення дворічної давнини поводяться під навантаженням, якого тоді не було.
Для карʼєри тут є непряма, але помітна різниця. Senior-питання на співбесідах питають переважно про другий набір досвіду: одночасність, стан у довгих процесах, міграції без простою, ціна рішення. Ми розбирали це окремо в статті «З Middle у Senior» і в підбірці senior-питань. Це не означає, що в аутсорсі такого досвіду немає — він є в командах, які ведуть проєкт роками і мають доступ до проду. Але якщо ваш формат — три місяці на проєкт і передача, готуватись до senior-співбесіди доведеться свідомо, бо робота вам ці ситуації не принесе.
Аутстаф — третій варіант, який плутають із продуктом
47 анкет, медіана $3 700, Senior $4 100 — між продуктом і аутсорсом, ближче до продукту. Формально ви сидите в продуктовій команді замовника, робите його бекенг, ходите на його стендапи. Практично контракт у вас із вендором, і саме звідти беруться обмеження, яких у штатного інженера немає.
Що варто зʼясувати до підписання, бо це відрізняється від контракту до контракту:
- Чи є у вас доступ до продакшену й до логів, чи ви пишете тікет їхньому інженеру.
- Чи входите ви в чергування — і якщо ні, чи не означає це, що вас не пускають до найцікавіших задач.
- Хто ухвалює архітектурні рішення і чи можете ви ініціювати рефакторинг, чи лише виконуєте беклог.
- Що станеться з вашим кодом, якщо контракт закінчиться раніше за проєкт.
Аутстаф дає продуктовий контекст без продуктової відповідальності. Комусь це рівно те, що треба; але якщо ви йдете туди по senior-досвід, перевірте, що вас пускають далі за тікети.
Як перевіряти оферт, а не медіану
Список питань, які змінюють відповідь сильніше за назву типу компанії:
- Скільки кодових баз у вас буде за рік? Одна — це продуктовий режим незалежно від вивіски. Пʼять — аутсорсний, теж незалежно від вивіски.
- Хто ставить версію PHP і фреймворку, і коли востаннє її піднімали? Відповідь «клієнт» і «два роки тому» означає, що ви будете писати під платформу з фіксованим набором можливостей.
- Хто чергує і хто розбирає інциденти? Це найшвидший спосіб зрозуміти, чи володієте ви продом.
- Куди в спринті йде час на технічний борг і хто його затверджує? Якщо відповідь «клієнт має погодити», борг не прибиратимуть.
- Скільки живуть проєкти? Три місяці й три роки — це дві різні професії з однаковою назвою.
- Яка вилка на моєму грейді, а не в компанії? Порівнюйте з фільтром по грейду в звіті і з відкритими вилками в каталозі вакансій.
І окремо про англійську. У тих самих даних крок від Intermediate до Upper-Intermediate — друга за величиною вісь після грейду. Аутсорс і аутстаф частіше ставлять вас у щоденне спілкування із замовником англійською; продукт із локальною командою може не ставити взагалі. Якщо ви обираєте на два кроки вперед, це аргумент на користь аутсорсу зараз і продукту потім.
Коли аутсорс — свідомо правильний вибір
Коли ви ще не знаєте, який домен вам цікавий: за два роки ви побачите фінтех, логістику і e-commerce і зрозумієте, з чим готові жити довго. Коли міняєте стек або повертаєтесь після паузи: сервісні компанії частіше беруть на зростання, бо їхня економіка на цьому побудована. Коли в вашому домені продуктових компаній із PHP просто немає поруч.
Коли він правильним не є: якщо ви вже Senior, працюєте за медіану свого типу компанії й останні два роки не бачили жодної задачі, у якій наслідки вашого рішення проявились би пізніше ніж через місяць. Тоді ви платите за стабільність двічі — сумою в контракті й досвідом, якого не отримуєте. Але перевіряти це варто по конкретних питаннях зі списку вище, а не по вивісці: у цих даних медіана — це властивість вибірки, а не вашого оферта.