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

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

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

Чому Flutter

Flutter дозволяє писати один застосунок одразу для iOS і Android на спільній кодовій базі. Це не робить розробку безкоштовною, але прибирає дублювання: інтерфейс, логіка і більша частина тестів пишуться один раз.

Де Flutter особливо доречний:

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

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

З чого складається вартість

Екрани і сценарії користувача

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

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

Дизайн

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

Бекенд

Застосунок майже ніколи не живе сам по собі. Йому потрібен сервер, який зберігає дані, перевіряє права, рахує ціни й надсилає сповіщення.

• Готова платформа. Firebase закриває авторизацію, базу даних, зберігання файлів і push-сповіщення. Швидкий старт, але згодом можуть з’явитися обмеження.
• Власний бекенд. Більше гнучкості та контролю над даними, але більше роботи на старті.
• Наявна система. Якщо у вас уже є сайт, CRM чи облікова система з API, застосунок може працювати поверх них. Тоді обсяг бекенду залежить від того, наскільки готовий цей API.

Адмін-панель

Хтось має керувати контентом, замовленнями, користувачами й акціями. Іноді вистачає наявної адмінки сайту, іноді потрібна окрема панель під мобільні сценарії.

Інтеграції

Кожна зовнішня система додає роботи: вивчення документації, обробку помилок, тестування.

• платежі: Stripe, PayPal, Apple Pay, Google Pay;
• доставка: DHL або локальні служби з розрахунком вартості й трекінгом;
• ERP і CRM: SAP, Odoo, Microsoft Dynamics або ваша власна система;
• карти й геолокація;
• аналітика і push-сповіщення;
• AI-функції через OpenAI API.

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

Публікація – окремий етап, а не кнопка. Потрібні акаунти розробника, іконки, скриншоти й описи, політика конфіденційності, відповіді на запитання про збір даних. Apple і Google перевіряють застосунки за своїми правилами, і часом доводиться вносити правки після рев’ю.

Тестування

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

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

Apple і Google регулярно оновлюють системи та вимоги. Бібліотеки застарівають, з’являються нові розміри екранів. Закладайте підтримку і розвиток від самого початку, а не після першого збою.

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

Чому одну ідею оцінюють по-різному

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

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

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

Що найбільше впливає на бюджет

• Робота без мережі. Офлайн-режим із подальшою синхронізацією помітно ускладнює логіку.
• Реальний час. Чати, трекінг кур’єра на карті, живі статуси.
• Платежі та підписки. Особливо покупки всередині застосунку з правилами магазинів.
• Ролі та права. Клієнт, кур’єр, менеджер, адміністратор – по суті кілька застосунків в одному.
• Складні інтеграції. Особливо із системами без нормального API.
• Нестандартний інтерфейс. Складні анімації та кастомні елементи замість стандартних компонентів.

Як почати з MVP

MVP – це мінімальна версія, яка розв’язує головну задачу користувача і дозволяє перевірити ідею на реальних людях. Не урізана копія фінального продукту, а його ядро.

1. Сформулюйте одну головну задачу: що користувач має зробити в застосунку.
2. Опишіть основний сценарій від входу до результату і відріжте все, що йому не служить.
3. Вирішіть, на чому будувати бекенд: готова платформа на кшталт Firebase для швидкої перевірки чи власний сервер, якщо дані й логіка вже складні.
4. Оберіть мінімум інтеграцій, без яких сценарій не працює.
5. Заплануйте аналітику, щоб після запуску бачити, як люди користуються застосунком.
6. Опублікуйте, зберіть зворотний зв’язок і лише потім додавайте функції.

Добрий приклад вузької задачі – застосунок кур’єра, який ми робили для Ricco Pizza: кур’єри отримують у ньому замовлення, а адреса і склад надходять на телефон одразу після передачі в доставку. Одна зрозуміла задача, пов’язана із сайтом і системою ресторану, без зайвого.

Як отримати точну оцінку

Щоб оцінка була близькою до реальності, надішліть нам:

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

За цим описом ми запропонуємо склад MVP і підготуємо оцінку з розбивкою за етапами.

Читайте на тему: на чому робити інтернет-магазин: OpenCart, WooCommerce, Shopify чи Laravel; гейміфікація в онлайн-бізнесі; коли час робити власну CRM замість готової.

Запросіть оцінку

Опишіть вашу ідею чи задачу через форму на сайті, у Telegram, WhatsApp або на e-mail. Поставимо уточнювальні запитання, запропонуємо, з чого почати, і підготуємо оцінку під ваш проєкт.