Як замовити мобільний застосунок для бізнесу: договір, оплата та гарантії

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

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

Як замовити мобільний застосунок для бізнесу та з чого почати

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

Які бізнес-завдання має вирішувати майбутній застосунок

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

Корисно також описати користувачів: клієнтів, партнерів або власних співробітників. Від цього залежать вимоги до інтерфейсу, авторизації, можливостей роботи без мережі та захисту даних.

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

Як визначити функціонал, бюджет і терміни мобільної розробки

Функціонал зручно ділити на три групи: те, без чого продукт не має сенсу; те, що підсилює цінність; і те, що можна відкласти на потім. Перша група стає основою MVP — мінімальної версії, яка дозволяє перевірити бізнес-гіпотезу на реальних користувачах і не витрачати бюджет на функції, попит на які ще не підтверджено.

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

Що підготувати перед зверненням до компанії-розробника

Мінімальний пакет, який заощадить кілька тижнів листування:

• опис бізнес-моделі та цільових користувачів;

• ключові сценарії: що користувач робить у застосунку від першого відкриття до цільової дії;

• приклади застосунків, які подобаються або не подобаються, з поясненням чому;

• перелік систем для інтеграції: CRM, ERP, облікова система, платіжний провайдер, служба доставки;

• наявні матеріали: брендбук, дизайн, API-документація, попередні напрацювання;

• обмеження: дедлайн, бюджет, вимоги до зберігання даних.

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

Чим розробка мобільних застосунків на замовлення відрізняється від готових рішень

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

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

Як вибрати розробника мобільних додатків і перевірити підрядника

Фрилансер, IT-компанія чи власна команда: кому довірити проєкт

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

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

Як оцінити портфоліо, технічну експертизу та досвід у вашій галузі

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

Перевірте досвід саме з вашими інтеграціями та обмеженнями: платежі, персональні дані, облікові системи, геолокація, офлайн-режим. Запитайте, як підрядник обирає між нативною розробкою під iOS та Android і кросплатформними технологіями на кшталт Flutter чи React Native. Якісна відповідь містить компроміси: кросплатформний підхід зменшує обсяг коду й вартість підтримки, а нативний доцільніший при глибокій роботі з апаратними можливостями пристрою чи специфічних вимогах до продуктивності. Сильний розробник мобільних додатків пояснює такий вибір через ваші бізнес-цілі, а не через вподобання команди.

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

• Хто конкретно працюватиме над проєктом і чи можлива заміна фахівців без погодження?

• Як влаштоване тестування: окремий QA, автотести, перевірка на реальних пристроях?

• Де зберігатиметься код і чи матиме замовник доступ до репозиторію з першого дня?

• Як оцінюються й погоджуються зміни функціоналу?

• Як часто відбуваються демонстрації проміжних результатів?

• На чиї акаунти публікуватиметься застосунок і реєструватимуться сторонні сервіси?

• Що входить у гарантію і скільки коштує подальша підтримка?

• Які практики безпечної розробки застосовуються: code review, статичний аналіз коду, перевірка залежностей?

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

На які ризики та ознаки ненадійного підрядника слід звернути увагу

Тривожні сигнали: точна ціна без жодного уточнювального питання; вимога 100% передоплати; відмова відкривати репозиторій до фінального платежу; розмиті формулювання на кшталт «додаток під ключ» без переліку функцій; небажання фіксувати права на код; відсутність QA у складі команди.

Окремий ризик – підрядник, який реєструє акаунти розробника в Apple і Google на себе. Технічно це спрощує старт, але фактично робить бізнес залежним від виконавця в найчутливішій точці: доставці оновлень користувачам. Застосунок має публікуватися з акаунта замовника, а команда підрядника отримує в ньому лише робочі ролі.

Договір на розробку мобільного застосунку: які умови потрібно зафіксувати

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

Предмет договору, обсяг робіт і технічне завдання

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

Якщо на момент підписання ТЗ ще немає, розумно укласти окремий договір або виділити етап Discovery, результатом якого стане документація, а вже під неї — основний договір на розробку.

Терміни виконання, проміжні результати та відповідальність сторін

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

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

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

Як прописати порядок внесення змін до функціоналу та бюджету

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

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

Кому належать вихідний код, дизайн і майнові права інтелектуальної власності

Це одне з найважливіших питань проєкту. В Україні правова охорона комп'ютерних програм детально врегульована новим Законом «Про авторське право і суміжні права» № 2811-IX, а розподіл майнових прав на твір, створений на замовлення, залежить від норм законодавства та умов договору. Розраховувати на «за замовчуванням» небезпечно: передача майнових прав інтелектуальної власності має бути прописана прямо.

У договорі варто перелічити об'єкти: вихідний код мобільних застосунків і серверної частини, дизайн-макети, тексти, структуру баз даних, технічну документацію. Зафіксуйте момент переходу прав (часто – після оплати відповідного етапу), обсяг прав, територію та строки. Окремо пропишіть використання бібліотек із відкритим кодом: замовнику потрібен перелік сторонніх ліцензій, щоб розуміти обмеження на комерційне використання.

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

NDA, конфіденційність і захист бізнес-даних

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

Умови розірвання договору та повернення невикористаних коштів

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

Етапи оплати розробки мобільного застосунку: як контролювати бюджет

Передоплата за мобільну розробку: коли вона обґрунтована

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

Fixed Price, Time & Material та Dedicated Team: яку модель оплати вибрати

Fixed Price та Time & Material часто поєднують: Discovery і MVP – за фіксованою ціною, подальший розвиток – погодинно. Так бізнес отримує передбачуваність на старті й гнучкість після запуску.

Зрозуміло, що фіксована ціна не означає відсутність ризиків для замовника: підрядник закладає в неї запас на невизначеність, а будь-яка зміна обсягу оформлюється окремо. Для Time & Material корисно встановити верхню межу бюджету на етап або місяць: якщо оцінка наближається до ліміту, виконавець зобов'язаний попередити про це заздалегідь, а не виставити рахунок постфактум. Такий механізм поєднує гнучкість оплати за фактом із передбачуваністю для фінансового планування.

Поетапна оплата за результат: Discovery, дизайн, розробка, тестування та реліз

Оплата розробки за етапами прив'язує гроші до результатів, які можна перевірити:

1. Discovery – документація, прототип, оцінка та календарний план.
2. UX/UI-дизайн – погоджені макети ключових екранів і дизайн-система.
3. Розробка – оплата за спринтами або модулями після демонстрації працюючого функціоналу на тестовому середовищі.
4. Тестування та стабілізація – після закриття критичних дефектів.
5. Реліз – фінальний платіж після публікації та передачі коду й доступів.

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

Як погоджувати акти виконаних робіт і перевіряти проміжні результати

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

Додаткові витрати: інтеграції, сервери, ліцензії та публікація застосунку

Кошторис IT-проєкту рідко обмежується роботою команди. Окремо плануються:

• хостинг і хмарна інфраструктура для серверної частини;

• акаунти розробника: річна підписка Apple Developer Program і разова реєстрація в Google Play Console;

• платні SDK, карти, аналітика, SMS-розсилки, сервіси push-повідомлень;

• комісії платіжних провайдерів і магазинів застосунків;

• доопрацювання на боці CRM чи ERP, якщо їхні API не готові до інтеграції.

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

Як уникнути перевищення кошторису та непередбачених платежів

Найбільше перевитрат виникає через невраховані інтеграції, «дрібні» зміни, погоджені усно, і пізнє тестування. Методи захисту від подібних проблем: оцінка ризиків у Discovery, буфер у бюджеті, письмова процедура змін, регулярні демо та щомісячні звіти про витрачений і залишковий бюджет. Контроль бюджету та термінів має бути регулярною процедурою, а не реакцією на проблему.

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

Етапи розробки мобільного застосунку мають бути відображені в календарному плані й пов'язані з графіком платежів.

Discovery та підготовка технічного завдання

Команда вивчає бізнес-процеси, користувачів і наявні системи, формує user stories, архітектуру, специфікацію API, оцінку та план робіт. Тут же фіксуються технічні ризики: чи має облікова система стабільний API, чи потрібна черга для синхронізації замовлень, як застосунок поводиться без зв'язку. Окремо визначаються середовища (розробки, тестове, продакшн) і вимоги до інфраструктури. Результат Discovery — не лише документ, а й обґрунтована оцінка: після цього етапу вартість і строки стають значно точнішими, ніж на першому зідзвоні, а замовник може ухвалити рішення про запуск розробки з розумінням ризиків.

Прототипування, UX/UI-дизайн і погодження інтерфейсу

Спочатку створюється клікабельний прототип для перевірки сценаріїв, потім UX/UI-дизайн мобільного інтерфейсу з урахуванням рекомендацій Apple і Google для своїх платформ. Погоджені макети стають частиною критеріїв приймання, що зменшує ризик суперечок у стилі “ми очікували іншого”.

Програмування застосунку для iOS та Android

Розробка ведеться ітераціями з регулярними демонстраціями. Паралельно триває розробка серверної частини: API, адмінпанель, бази даних, сервіс сповіщень. Код зберігається в репозиторії, до якого замовник має доступ, а збірки через CI/CD розгортаються на окремі середовища. Кожна зміна проходить code review, а збірка — автоматичні перевірки.

Інтеграція з CRM, ERP, платіжними системами та API

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

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

Тестування функціоналу, продуктивності й безпеки

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

Публікація в App Store і Google Play та передача готового продукту

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

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

Гарантійне виправлення помилок після запуску

Гарантія на розробку мобільного додатку означає, що виконавець безоплатно виправляє дефекти – невідповідності погодженому ТЗ, виявлені протягом визначеного строку після приймання. Вона не охоплює нові функції, зміну вимог чи наслідки втручання третіх осіб у код.

Крім того, у договорі варто окремо обумовити ситуації, які не є дефектами виконавця, але можуть порушити роботу застосунку: вихід нової версії iOS чи Android після приймання, зміна API стороннього сервісу, оновлення правил магазину застосунків. Зазвичай адаптація до таких змін виконується в межах технічної підтримки. Якщо ж межа не визначена, кожен подібний випадок стає предметом суперечки про те, хто має платити.

Як зафіксувати гарантійний термін та умови усунення дефектів

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

Гарантії якості, безпеки та відповідності технічному завданню

Крім виправлення помилок, договір може гарантувати, що код не має шкідливих компонентів, не порушує права третіх осіб, а використані відкриті бібліотеки сумісні з комерційним використанням. Корисно зафіксувати мінімальні стандарти якості: code review для кожної зміни, обов'язкові перевірки безпеки під час збірки, підтримку погоджених версій iOS та Android.

Що робити, якщо розробник порушує терміни або не виконує зобов'язання

Діяти за договором: письмова претензія з описом порушення, строк на усунення, застосування штрафних санкцій, у крайньому разі – розірвання з отриманням коду й поверненням невикористаних коштів. Усі домовленості та порушення мають бути зафіксовані письмово. Листування в месенджерах складніше використати як доказ, тому важливі рішення варто дублювати електронною поштою або в системі управління задачами.

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

Чим гарантійне обслуговування відрізняється від платної технічної підтримки

Гарантія покриває дефекти, які існували на момент приймання. Технічна підтримка після запуску – окрема платна послуга: моніторинг, адаптація до нових версій iOS та Android, оновлення бібліотек, дрібні доопрацювання, адміністрування серверів. Для неї окремо погоджують SLA та строки реагування, пакет годин і ціну. Плутанина цих понять – поширене джерело конфліктів, тому межу варто чітко описати в договорі.

Приймання готового застосунку: що перевірити перед фінальною оплатою

Функціональне тестування та перевірка відповідності ТЗ

Критерії приймання програмного продукту краще погодити заздалегідь: перелік сценаріїв, що мають працювати, список пристроїв і версій ОС, допустима кількість некритичних дефектів. Під час приймання пройдіть ключові сценарії самостійно або залучіть незалежного QA-фахівця. Перевіряйте не лише «щасливий шлях», а й граничні випадки: втрату зв'язку під час оплати, повторне натискання кнопки, вхід з нового пристрою, роботу з повільним інтернетом.

Передача вихідного коду, репозиторіїв, документації та доступів

Передача – це не архів із кодом. Повний пакет зазвичай містить:

• репозиторії мобільних застосунків, серверної частини та адмінпанелі з історією змін;

• інструкції зі збирання й розгортання, налаштування CI/CD;

• технічну документацію: архітектуру, специфікацію API, схему бази даних;

• дизайн-файли, прототипи, беклог, записи ключових рішень;

• доступи до серверів, баз даних, акаунтів сторонніх сервісів;

• перелік відомих обмежень і технічного боргу;

• опис інтеграцій, моніторингу та логування.

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

Як перевірити готовність застосунку до реального навантаження

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

Акт приймання-передачі: що має отримати замовник

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

Як забезпечити можливість подальшої роботи з іншим підрядником

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

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

Типові помилки бізнесу під час замовлення мобільної розробки

Початок розробки без детального технічного завдання

Без ТЗ неможливо ані точно оцінити роботу, ані прийняти її. Будь-яка розбіжність у баченні стає конфліктом, а Fixed Price без специфікації перетворюється на суперечку про те, що «малося на увазі». Discovery обходиться значно дешевше, ніж переписування готового функціоналу. Навіть якщо бізнес поспішає, кілька тижнів на документацію зазвичай виправдані через меншу кількість переробок і чіткі критерії приймання.

Вибір підрядника лише за найнижчою ціною

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

Повна оплата проєкту до передачі результатів

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

Відсутність у договорі умов передачі майнових прав на програмний продукт

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

Ігнорування витрат на підтримку, оновлення та масштабування

Застосунок потребує регулярних оновлень: Apple і Google щороку випускають нові версії ОС і змінюють вимоги до публікації, бібліотеки застарівають, навантаження зростає. Супровід і масштабування продукту варто закладати в бюджет одразу, інакше через рік-два застосунок може стати вразливим або втратити сумісність із новими версіями ОС.

Чекліст замовника: що перевірити перед підписанням договору

Документи, які потрібно погодити з IT-підрядником

• NDA, підписаний до передачі чутливої інформації.

• Основний договір і технічне завдання або специфікація як додаток.

• Календарний план із контрольними точками.

• Порядок управління змінами та форма запиту на зміну.

• Умови технічної підтримки й SLA, якщо підтримка потрібна після запуску.

Умови оплати, гарантії та відповідальність виконавця

• Модель оплати та прив'язка платежів до етапів.

• Розмір авансу, що не перевищує вартості найближчого етапу.

• Перелік додаткових витрат і того, хто їх оплачує.

• Гарантійний строк, класифікація дефектів і строки виправлення.

• Штрафні санкції та відповідальність сторін із розумними лімітами.

• Порядок розірвання й повернення невикористаних коштів.

Контрольні точки, критерії приймання та звітність за проєктом

• Регулярні демонстрації на тестовому середовищі.

• Критерії приймання для кожного етапу.

• Строки розгляду актів і порядок фіксації зауважень.

• Звіти про витрачені години та залишок бюджету.

Права на код, доступи та технічна незалежність бізнесу

• Явна передача майнових прав на код, дизайн і документацію.

• Перелік сторонніх бібліотек і їхніх ліцензій.

• Репозиторій, хостинг, акаунти Apple і Google оформлені на замовника.

• Погодження субпідрядників і їхні зобов'язання щодо конфіденційності.

• Право на незалежний аудит коду.

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

FAQ