Скільки часу займає розробка мобільного додатка

Простий мобільний додаток зазвичай розробляють за 2–4 місяці, додаток середньої складності — за 4–7 місяців, а складний продукт з великою кількістю інтеграцій чи жорсткими вимогами регулятора — за 8–12 місяців і більше. MVP з чітко обмеженим набором функцій часто можна запустити за 2–4 місяці.

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

Середні терміни розробки додатка

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

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

Ось як може виглядати календар додатка середньої складності, якщо його роблять крос-платформно, а клієнт відповідає за день-два:

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

Терміни розробки за етапами

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

Discovery і вимоги

Тривалість: 2–4 тижні для більшості додатків, до 6–8 тижнів для складних платформ.

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

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

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

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

UX/UI дизайн

Тривалість: 3–8 тижнів залежно від кількості екранів і ролей користувачів.

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

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

Розробка

Тривалість: 2–6 місяців для більшості додатків, довше для складних платформ.

Це найдовший етап, і він охоплює три шари:

• Frontend, сам мобільний додаток: екрани, навігація, локальне зберігання, робота офлайн, push-сповіщення.

• Backend, серверна частина: бізнес-логіка, база даних, керування користувачами, адмінка.

• API, шар, який з’єднує додаток з backend і сторонніми сервісами: оплатою, картами, CRM.

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

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

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

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

QA і тестування

Тривалість: паралельно з розробкою, плюс 2–4 тижні стабілізації перед релізом.

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

Перед релізом команда роздає бета-версії закритій групі тестувальників. На iOS це зазвичай TestFlight, на Android — закрите тестування в Google Play Console.

Окремо про Android. Пристроїв під цією системою значно більше, ніж моделей iPhone: різні виробники, розміри екранів, версії системи і власні оболонки. В Україні Android має помітну частку ринку, тому тестування на кількох реальних пристроях різних цінових сегментів — не розкіш, а необхідність. Закладайте на це час у плані QA.

Публікація та рев’ю в сторах

Тривалість: від кількох днів до 3 тижнів.

Обидва магазини перевіряють додатки перед публікацією. За даними Apple, більшість заявок в App Store розглядають протягом 24 годин, хоча перша публікація і додатки з чутливих категорій можуть перевірятися довше, а відмови додають нові цикли. Рев’ю в Google Play зазвичай триває від кількох годин до кількох днів.

Є деталь, яка часто стає несподіванкою. Google вимагає від розробників з особистими акаунтами, створеними після 13 листопада 2023 року, провести закрите тестування щонайменше з 12 тестувальниками протягом щонайменше 14 днів, перш ніж опублікувати додаток. На акаунти організацій це правило не поширюється, але якщо публікуєте з особистого акаунта, закладайте два додаткові тижні.

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

Підтримка після запуску

Тривалість: постійно.

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

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

Час, про який легко забути. Частина роботи взагалі не залежить від розробників, але впливає на дату запуску:

• Акаунти розробника. Щоб публікуватися в App Store від імені компанії, треба зареєструватися в Apple Developer Program як організація, а для цього потрібен номер D-U-N-S. Якщо його в компанії ще немає, отримання може зайняти від кількох днів до кількох тижнів. Google Play для акаунтів організацій теж вимагає номер D-U-N-S і перевіряє особу розробника та дані організації.

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

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

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

Починайте ці задачі на етапі дизайну, а не за тиждень до релізу.

Терміни за типом додатка

Етапи однакові для всіх додатків. Відрізняється обсяг роботи всередині кожного. Ось що робить поширені типи коротшими або довшими.

MVP

Типовий термін: 2–4 місяці.

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

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

e‑commerce додаток

Типовий термін: 4–7 місяців.

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

Додаток для доставки

Типовий термін: 6–10 місяців.

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

Фінтех-додаток

Типовий термін: 8–12+ місяців.

Фінтех-додатки довші через вимоги регулятора і безпеку, а не через екрани. KYC-перевірки, моніторинг транзакцій, захист персональних даних, інтеграції з банками і платіжними системами додають роботи. В Україні до цього часто додаються вхід і верифікація через BankID або підписання документів через Дія.Підпис, а кожна з цих інтеграцій має власні умови підключення і тестування. Більшість фінтех-продуктів також проходять зовнішній аудит безпеки і пентест перед запуском, і виправлення знахідок займає час.

Маркетплейс і соцмережа

Типовий термін: 6–12 місяців.

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

Корпоративний додаток

Типовий термін: 9–12+ місяців.

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

iOS чи Android першим: як це впливає на терміни. Якщо бюджет чи команда не дозволяють запускати обидві платформи одночасно, доводиться обирати, з чого почати. Рішення залежить від аудиторії. В Україні Android має велику частку користувачів, особливо в масових сегментах, тому для сервісів доставки, роздрібу чи фінансових продуктів широкого вжитку Android часто важливіший. Для преміальних сервісів і B2B-продуктів з аудиторією у США чи окремих країнах Західної Європи, де частка iPhone вища, часто логічно почати з iOS. Перш ніж вирішувати, перевірте частку платформ саме на ваших цільових ринках.

Технічно платформи відрізняються не так сильно, як здається, але є нюанси. Пристроїв Android набагато більше, тож тестування займає більше часу. На iOS менше моделей, зате суворіші вимоги до рев’ю і дизайну за Apple Human Interface Guidelines. Крос-платформна розробка знімає більшу частину цього вибору, бо дозволяє випустити обидві версії майже одночасно, а різницю в часі зводить до тестування і публікації.

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

Що впливає на терміни розробки

Ось основні фактори приблизно в порядку їхнього впливу.

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

Кількість платформ. Додаток для iOS, Android і web з погляду користувача — це три продукти, навіть якщо частина коду спільна. Запуск спершу на одній платформі і додавання інших згодом — цілком робоча стратегія.

Нативна чи крос-платформна розробка. Нативні додатки для iOS пишуть на Swift, для Android — на Kotlin. Це дві окремі кодові бази і дві лінії розробки. Крос-платформні фреймворки Flutter і React Native дозволяють одній команді зробити обидва додатки зі спільної кодової бази, що для типових бізнес-додатків зазвичай помітно економить час. Нативна розробка досі має сенс для додатків, які інтенсивно використовують «залізо» пристрою, складні анімації чи найновіші функції платформ. Детальніше про переваги розробки на Flutter і розробку додатків на React Native ми писали окремо.

Інтеграції. Оплата, карти, CRM, ERP, аналітика, служби доставки, BankID. Добре задокументовані API підключаються за дні. Старі чи погано описані системи можуть забрати тижні, і часто це неможливо знати, поки команда не почне з ними працювати.

Вимоги регулятора. Захист персональних даних, GDPR для користувачів з ЄС, KYC для фінансових сервісів, вимоги доступності. Кожна вимога додає документацію і тестування.

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

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

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

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

Добра оцінка враховує всі ці фактори і закладає буфер на ризики. Тому чесна відповідь на питання про терміни завжди звучить як діапазон, а не одна дата, і звужується після discovery.

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

Чому оцінка змінюється і коли їй можна довіряти. Оцінка, зроблена за ідеєю на одну сторінку, легко може помилятися вдвічі, бо ніхто ще не знає деталей кожної функції, інтеграції й нестандартних сценаріїв. Після discovery, коли зрозумілі user stories, макети ключових екранів і вимоги до інтеграцій, діапазон стає значно вужчим. Це нормально, тому досвідчені команди на старті дають діапазон, а точніший план — після discovery. Якщо хтось після 30-хвилинного дзвінка називає точну дату для складного додатка, запитайте, на яких припущеннях вона тримається.

Українська специфіка, яка впливає на терміни. Мовні версії додають не лише переклад, а й тестування кожної мови: довші українські й російські слова часто ламають кнопки і заголовки, розраховані на англійську. Інтеграції з «Новою поштою», LiqPay, monobank чи Checkbox зазвичай мають зручні API, але кожна потребує тестових акаунтів і перевірки на реальних сценаріях. Вхід через BankID чи Дія.Підпис вимагає окремого підключення і погоджень, тож закладайте на це час із самого початку.

Як прискорити розробку без втрати якості

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

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

Обирайте крос-платформну розробку, коли вона підходить. Flutter чи React Native для типових бізнес-додатків означає одну кодову базу замість двох.

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

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

Автоматизуйте через CI/CD. Безперервна інтеграція і доставка автоматично збирають, тестують і роздають додаток після кожної зміни. Тестувальники отримують нові збірки за хвилини, а підготовка релізу перестає бути ручним проєктом.

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

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

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

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

Приклад з реального проєкту

Sailica — це онлайн-платформа бронювання яхт з Великої Британії. Першим етапом був web-MVP, який наша команда з 8 фахівців зробила за 3 місяці. Це стало можливим завдяки вузькому обсягу: MVP покривав ключовий сценарій пошуку і бронювання яхти, а решта продукту виростала з нього в наступних релізах.

Коли web-платформа довела свою цінність, наступним кроком став нативний iOS-додаток. Команда з 5 спеціалістів зробила його на Swift приблизно за 440 годин роботи. Оскільки backend, бізнес-логіка і візуальна мова вже існували, додаток використав їх замість старту з нуля. Це типовий ефект добре спланованого MVP: другий продукт робиться швидше, бо перший уже відповів на найскладніші питання.

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

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