Терміни розробки мобільного застосунку: скільки часу це займає

Коротка відповідь

Як орієнтир для студій в Україні та Східній Європі на 2026 рік, терміни для бізнес-застосунків укладаються в такі межі. Вартість тих самих типів — у статті скільки коштує розробка мобільного застосунку.

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

В EVA-X MVP зазвичай займає близько чотирьох тижнів; проста перша версія в AI Build буває швидшою, платформа з кількома ролями — довшою. Формат розробки — AI Build, AI + DEV чи DEV — обирають для кожного проєкту окремо, і він рухає не лише ціну, а й терміни.

Куди насправді йдуть тижні

Визначення обсягу робіт

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

Дизайн

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

Бекенд і адмінка

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

Екрани застосунку

На React Native з Expo більшість екранів пишуть один раз для iOS та Android. Нативна розробка приблизно подвоює цю частину, бо більшість функцій доводиться писати двічі. Коли це виправдано, ми розібрали в статті React Native чи нативна розробка.

Інтеграції

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

Тестування на реальних пристроях

Різні розміри екранів, версії ОС, повільний інтернет, заборонені дозволи, застосунок, згорнутий посеред оплати. Саме тут виринає все, що зробили «на швидку руку».

Публікація в App Store і Google Play

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

Що затягує розробку

• Більше ролей. Застосунок для клієнтів — це один продукт. Клієнти, працівники й адміністратори — це три, навіть якщо в них спільний бекенд.
• Оплати, де гроші йдуть назовні. Прийняти платіж просто. Повернення, виплати продавцям, комісії та спори — ні.
• Офлайн-режим і синхронізація. Форми, що працюють без зв’язку й синхронізуються згодом, потребують ретельної роботи з конфліктами.
• Функції в реальному часі: відстеження, чати, живі статуси.
• Інтеграції без нормального тестового середовища або з довгим погодженням у партнера.
• Нестандартна анімація й дизайн замість чистого, звичного інтерфейсу.
• Неготові контент і дані: каталоги товарів, тексти, юридичні документи, тестові акаунти.
• Вимоги регуляторів: перевірка особи, фінансові чи медичні дані, вікові обмеження.
• Форс-мажор. У договорах з українськими командами форс-мажор може враховувати воєнний стан; у нашому — враховує. Прочитайте, як це прописано у вашому, і запитайте команду, як вона працює під час відключень світла.
• Повільні рішення. Тиждень очікування відгуку — це тиждень, доданий до термінів. Добре складений договір подовжує терміни на час затримок з боку клієнта; наш — теж.

Що пришвидшує

• Одна кодова база для iOS та Android на React Native з Expo.
• Готовий бекенд або API, до якого можна під’єднати застосунок.
• Перша версія, обрізана до того, що потрібно першим користувачам. Вирішити, що може почекати, допоможе стаття про функції першої версії застосунку.
• Формат розробки з AI для рутинних частин, де критичну логіку ведуть інженери.
• Одна людина з вашого боку, яка ухвалює рішення й відповідає на запитання протягом дня.
• Акаунти розробника, зареєстровані заздалегідь, щоб публікація не чекала на папери.

Кроки в App Store і Google Play, які не пришвидшиш

Акаунти розробника

Застосунок варто публікувати з ваших власних акаунтів розробника, щоб сторінки застосунку були вашими з першої версії. Зареєструйте їх заздалегідь. Для акаунта компанії в Apple Developer Program потрібен номер D-U-N-S, і якщо його у вашої компанії ще немає, отримання може затягтися. Google Play теж перевіряє особу розробника. Нічого складного, але це може непомітно заблокувати вже готовий застосунок.

Тестування в Google Play для нових акаунтів

Нові особисті акаунти розробника в Google Play мають провести закрите тестування з мінімальною кількістю тестувальників протягом визначеного часу, перш ніж отримають доступ до публікації. На момент написання статті це 12 тестувальників протягом 14 днів поспіль. Для акаунтів організацій правила інші. Перевірте актуальні вимоги в довідці Play Console, перш ніж планувати дату запуску. Якщо це ваш випадок, запускайте тестування, поки ще доробляються останні модулі.

Модерація в App Store

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

• рецензент не може увійти, бо йому не дали демо-акаунт;
• дані про конфіденційність на сторінці в App Store не збігаються з тим, що збирає застосунок;
• застосунок дає змогу створити акаунт, але не дає його видалити;
• цифрові товари продаються в обхід вбудованих покупок Apple;
• застосунок падає або в ньому лишилися тексти-заглушки.

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

Модерація зазвичай додає кілька днів до першої версії; на сторінці App Review Apple на момент написання вказує, що більшість заявок перевіряє протягом 48 годин. Наступні оновлення проходять швидше, а з Expo дрібні виправлення в JavaScript можна випускати «по повітрю», без нової модерації.

Жорстка дата? Фіксуйте дату, а не обсяг

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

Корисна вправа — розкласти всі функції на три колонки: потрібно в день запуску, потрібно протягом місяця після нього і «було б добре». Перша колонка визначає терміни. Дві інші стають наступними версіями.

Швидка самоперевірка, перш ніж питати про терміни

Відчути свої терміни можна ще до розмови з будь-ким:

• Порахуйте ролі. Хто користується застосунком і хто ним керує? Кожна роль — це окремий набір екранів і доступів.
• Випишіть головні сценарії. Реєстрація, головна дія, оплата і кілька речей, які люди роблять щодня. Не кожен екран, а саме шляхи.
• Перелічіть зовнішні системи. Оплати, карти, доставка, CRM, облік, перевірка особи. Позначте, до яких із них у вас уже є акаунти й доступи.
• Позначте невідоме. Усе, про що ви сказали б «якось розберемося», — саме там терміни й розтягуються.

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

Для наочності: перша версія за вісім тижнів

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

1. Тиждень 1. Обсяг підтверджено, ключові сценарії намальовано, акаунти розробника в процесі.
2. Тижні 2–3. Акаунти, профілі, каталог послуг; основа бекенду й адмінки.
3. Тижні 4–5. Бронювання, календар, оплати й квитанції.
4. Тиждень 6. Інструменти адмінки, сповіщення, звіти.
5. Тиждень 7. Тестування на пристроях, виправлення, сторінки в магазинах застосунків.
6. Тиждень 8. Подання в App Store і Google Play, модерація, запуск.

Це ілюстрація, а не пропозиція. Додайте роль, інтеграцію чи офлайн-режим — і план зсунеться.

Після запуску: як швидко можна щось змінити?

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

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

Як терміни фіксуються в EVA-X

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

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