Як обрати компанію з розробки програмного забезпечення у 2026: чекліст замовника

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

Більшість провальних проєктів у розробці стаються не через поганих інженерів. Вони стаються тому, що партнера обрали з невідповідними мотивацією, процесом чи рівнем досвіду, і зрозуміли це на четвертому місяці. Нижче - що перевіряти, що питати і що має закінчувати розмову.

На що дивитися, коли обираєте компанію з розробки ПЗ

Сім критеріїв передбачають результат краще, ніж будь-що в комерційній пропозиції:

• Зроблені продукти, які можна відкрити. Не логотипи й не скриншоти. Живі продукти, бажано зі складністю, схожою на вашу. Компанія з реальними кейсами може розповісти, що в кожному пішло не так, бо щось завжди йде не так.
• Хто буде на вашому проєкті, поіменно. Просіть конкретних людей, їхній рівень і скільки їхнього тижня ви отримуєте. Найпоширеніша підміна в галузі - senior-команда на продажному дзвінку і джуніори на розробці.
• Хто перевіряє код. У 2026 значну частину коду пишуть з AI - і в хороших компаніях, і в поганих. Різниця в тому, чи відповідають досвідчені інженери за архітектуру й чи перевіряють результат. Питайте прямо і підозріло ставтеся до обох крайніх відповідей: «ми не використовуємо AI» - це повільно й дорого, «AI пише все» - це коли за дорогі помилки не відповідає ніхто.
• Як діють при зміні обсягу. Вона трапляється в кожному проєкті. Питайте, що процедурно відбувається, коли ви просите щось нове на четвертому тижні. Хороша відповідь містить оцінку впливу на терміни й бюджет до того, як хтось почне робити.
• Чи вони сперечаються. Партнер, який погоджується з кожною вимогою, продає години, а не результат. Команди, яких варто наймати, скажуть, які функції зрізати і чому, ще в першій розмові, до того як їм щось заплатили.
• Що лишається вашим наприкінці. Репозиторії, акаунти інфраструктури, домени, дизайни, документація. Це має бути однозначно в договорі й у ваших власних акаунтах, а не в їхніх.
• Як ви бачитимете прогрес. Робочий софт щотижня кращий за статус-звіти. Якщо ви не можете клікнути щось справжнє наприкінці третього тижня, вам нічим перевірити те, що вам розповідають.

Питання для першого дзвінка

П'ять питань роблять більшу частину відсіву й займають хвилин двадцять:

1. «Хто пише код і хто його перевіряє?» Вам потрібні конкретні люди й зрозумілий процес рев'ю, а не «пул ресурсів».
2. «Що б ви зрізали з мого обсягу і чому?» Одразу перевіряє продуктове мислення. Підрядник без думки просто не думав про ваш продукт.
3. «Що буде, якщо я передумаю на четвертому тижні?» Перевіряє чесність процесу.
4. «Покажіть щось живе й схоже на це.» І відкрийте це на телефоні просто під час дзвінка.
5. «Що лишається моїм після завершення і як мені піти?» Компанія, впевнена у своїй роботі, робить вихід легким. Прив'язка - це бізнес-модель, а не випадковість.

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

Червоні прапорці, через які варто піти

• Фіксована ціна без дискавері. Тверда цифра до того, як хтось описав обсяг, - це або запас на ризик, або конвеєр додаткових угод потім. І те, і те коштує вам.
• Пропозиція значно нижча за ринок. Нереалістично дешево - це помилка в оцінці обсягу, за яку ви заплатите змінами або переробкою.
• Жодних заперечень. Див. вище. Згода - це не узгодженість.
• Ви не бачите команду. Немає імен, немає прямого контакту з інженерами, уся комунікація через акаунт-менеджера.
• Оцінки без діапазонів. Чесна оцінка дає діапазони й припущення. Впевненість на цьому етапі - це техніка продажу.
• Розмиті відповіді про AI. У 2026 його використовує кожна серйозна команда. Якщо відповідь ухильна, перепитайте й слухайте, хто відповідає за результат.

Моделі оплати і хто несе ризик

Модель оплати визначає, хто платить, коли оцінка виявилася хибною, - і тому важить більше за ставку:

• Фіксована ціна за фіксований обсяг. Ви знаєте суму. Ризик оцінки несе підрядник і закладає його в ціну. Найкраще для чітко описаної першої версії. Потребує записаного обсягу, тобто спершу дискавері.
• Час і матеріали. Ви платите за години. Ризик перевитрат несете ви, натомість отримуєте свободу міняти напрям. Найкраще для роботи після запуску і найгірше як безлімітний чек на першу збірку.
• Виділена команда або аутстафінг. Місячна ставка за людину, зазвичай $3,000-$8,000 за розробника. Ви ними керуєте, тож ризик доставки несете ви. Підходить компаніям із власним технічним керівництвом, яким потрібна потужність, а не відповідальність за результат. Ширше про цю модель - у статті аутстафінг чи аутсорсинг.

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

Де тут DForce, чесно

Ми AI-first продуктова студія. Наша зроблена робота - це проєктний аутсорсинг: ми беремо обсяг і відповідаємо за нього від початку до кінця, від ідеї до продукту в продакшені, - 22 кейси. Оскільки ми пишемо код через AI-пайплайн і лишаємо senior-інженерів на архітектурі й рев'ю, ми віддаємо той самий обсяг помітно дешевше, ніж традиційна агенція, і швидше. Ми також надаємо аутстафінг, коли клієнту потрібна потужність, а не відповідальність за результат, - але наш послужний список саме в зроблених проєктах, а не в наданих командах, і ми краще скажемо це прямо, ніж вдаватимемо інше.

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

Дотично корисне: наш розбір реальної вартості MVP у 2026 і як наймати розробників у стартап.

Часті запитання

Як обрати компанію з розробки програмного забезпечення? Оцінюйте чотири речі: реальні зроблені продукти, які можна відкрити й покористуватися, хто конкретно писатиме й перевірятиме ваш код, як компанія діє при зміні обсягу і чи хтось узагалі сперечається з вашими вимогами. А тоді купіть щось маленьке - оплачене дискавері або перший етап - перш ніж замовляти весь проєкт. Короткий платний старт скаже більше, ніж будь-яка кількість презентацій.

Скільки має коштувати розробка ПЗ у 2026? Перша робоча версія від AI-first команди зазвичай коштує $3,000-$20,000, складний продукт - $20,000-$45,000 і більше. Традиційні агенції зазвичай називають у 2-3 рази більше за той самий обсяг. Пропозицію, що значно нижча за ринок, сприймайте як помилку в оцінці обсягу, за яку заплатите пізніше.

Які питання поставити компанії з розробки? Питайте, хто саме пише код і хто його перевіряє, що відбувається при зміні обсягу посеред проєкту, як вони використовують AI і хто відповідає за результат, що ви отримуєте у власність наприкінці разом із репозиторіями та інфраструктурою, і попросіть показати схожий проєкт, який працює сьогодні.

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