Як обрати підрядника для розробки мобільного застосунку

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

Починайте з проблеми, а не з пітчу

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

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

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

Як перевірити портфоліо

Кейси в портфоліо — це маркетинг, а не докази. Важливо те, що за ними. При оцінці минулих робіт будь-якої агенції ставте три запитання.

Чи можна поговорити з клієнтом напряму? Будь-яка поважна агенція запропонує хоча б один референс-дзвінок з попереднім клієнтом. Якщо відмовляють — це вже сигнал. На дзвінку спитайте конкретно: чи здали проєкт вчасно? Що ламалось у продакшні в перші три місяці? Чи найняли б їх знову?

Чи живий застосунок насправді? Завантажте його. Перевірте рейтинг в App Store і відгуки. Подивіться на дату останнього оновлення. "Ключовий кейс", який не оновлювався два роки і має рейтинг 2,8 — не референс, а застереження.

Чи відповідає їхній стек вашій задачі? Якщо потрібен Flutter-застосунок, шукайте підрядників, які вже запускали Flutter у продакшн, а не тих, хто "теж робить Flutter" серед восьми технологій. Глибина в конкретному стеку важливіша за широту. У Codevia ми зосереджені на Flutter, React Native і .NET — не тому, що не вміємо інше, а тому, що продакшн-глибина в кількох стеках перевершує поверхневе знання багатьох.

Червоні прапорці, які мають зупинити розмову

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

• Відсутність фази дискавері. Якщо підрядник надсилає пропозицію з фіксованим скопом і ціною, не поставивши жодного запитання про домен, користувачів чи дані — він вгадує. Цей скоп розвалиться одразу після початку розробки.
• Розмиті deliverables. "Розробка мобільного застосунку" — не deliverable. Застосунок, що пройшов App Store review, має юніт-тести з покриттям від 60%, використовує задокументований підхід до управління станом та включає архітектурний документ — ось deliverable. Якщо контракт не визначає, що означає "готово" — підрядник визначить це сам.
• Відсутність QA в команді. Агенції без QA-ролі здадуть вам баги і назвуть це приймальним тестуванням.
• Код ваш тільки після повної оплати. Деякі агенції утримують права на код до сплати фінального інвойсу. У разі спору це лишає вас ні з чим. Наполягайте на власності коду з першого коміту в репозиторії, який контролюєте ви.
• "Архітектуру визначимо по ходу." Архітектура, що виникає хаотично від спринту до спринту — це технічний борг під іншою назвою.
• Команда з джунів, ціна як за сеньорів. Запитайте, хто насправді працюватиме на вашому проєкті. Люди на сейлз-дзвінку рідко є тими, хто пише код.

Питання для оцінювального дзвінку

Мета — вийти за межі завчених відповідей і зрозуміти реальну модель роботи підрядника.

1. Розкажіть про проєкт, який пішов не за планом. Що пішло не так, як ви це виявили і що зробили? Підрядники з реальним досвідом мають реальні провальні історії. Ті, в кого немає — дадуть гіпотетичну відповідь.
2. Який ваш процес між затвердженням дизайну і першим тестовим білдом? Це розкриває підхід до handoff, рішення щодо state management і визначення API-контракту.
3. Як ви обробляєте зміни скопу посеред проєкту? Є правильні і неправильні відповіді. Правильна: формальний процес контролю змін з оцінкою впливу. Неправильна: "ми гнучкі, просто скажіть нам."
4. Як виглядає підтримка після запуску? Баги в продакшні після релізу неминучі. Який їхній SLA? Чи це включено або виставляється окремо?
5. Чи можу я переглянути зразок коду? Навіть публічний GitHub-репозиторій дає сигнал про якість коду, культуру комітів і звички документування.

Фіксована ціна vs Time-and-Materials: коли що обирати

Модель взаємодії важливіша, ніж більшість замовників усвідомлює. Невідповідна модель для вашої стадії проєкту створюватиме тертя незалежно від якості підрядника.

Фіксована ціна працює, коли скоп справді добре визначений: є вайрфрейми, API-специфікація, чіткі критерії прийняття. Ви перекладаєте ризик скопу на підрядника. Він закладає цей ризик у ціну — тому платите більше, але маєте передбачуваність витрат.

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

Time-and-materials (T&M) працює, коли вам потрібна гнучкість. Ви платите за фактично витрачений час, можете вільно змінювати пріоритети. Ризик, який ви приймаєте — непередбачуваність витрат.

Для більшості стартап-MVP найкраща структура — T&M з обмеженим бюджетом і щомісячними milestone check-ins. Ви отримуєте гнучкість без відкритого ризику вартості.

Чек-лист due diligence

Використовуйте його перед підписанням будь-якого контракту з партнером з розробки мобільних застосунків.

Чек-лист перевірки підрядника

Портфоліо
[ ] Завантажили і протестували щонайменше два живих застосунки
[ ] Перевірили рейтинги і нещодавні відгуки в App Store / Play Store
[ ] Підтвердили, що застосунки підтримуються (останнє оновлення до 6 міс.)
[ ] Провели щонайменше один референс-дзвінок з попереднім клієнтом

Технічне
[ ] Підтвердили, хто саме працюватиме на вашому проєкті
[ ] Запитали про архітектурний підхід і отримали конкретну відповідь
[ ] Переглянули публічний код або отримали зразок
[ ] Підтвердили наявність QA-ролі в команді
[ ] Запитали про очікування щодо тестового покриття

Комерційне
[ ] Підтвердили власність коду з першого коміту
[ ] Перевірили клаузули про IP у контракті
[ ] Підтвердили доступ до репозиторію (він належить вам)
[ ] Зрозуміли процес контролю змін
[ ] Зрозуміли умови і вартість підтримки після запуску

Процес
[ ] Фаза дискавері або скопінгу включена в роботу
[ ] У контракті визначено, що означає "готово"
[ ] Погоджено каденцію спринтів і розклад демо
[ ] Задокументовано шлях ескалації для спорів

Як виглядає "добре" насправді

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

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

Готові оцінити Codevia?

Ми будуємо мобільні продукти на Flutter і React Native для стартапів і SMB. Працюємо прозоро — репозиторій ваш з першого дня, архітектурні рішення документуємо по ходу, не беремося за проєкти, де не можемо бути чесними щодо скопу.

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