1Нативное или кроссплатформенное
Нативная разработка — это два отдельных приложения: одно под iOS, другое под Android, каждое на своём стеке. Кроссплатформенная (React Native и аналоги) — одна кодовая база, которая собирается под обе системы. Для бизнес-приложений — запись, каталог, оплаты, уведомления, личный кабинет — кроссплатформа стала разумным дефолтом: быстрее, дешевле, и пользователь разницы не видит.
Нативный путь оправдан, когда нужен максимум от платформы: тяжёлая графика, работа с железом, специфичные системные API. Если подрядчик предлагает два нативных приложения для сервиса записи «потому что так качественнее» — это повод спросить, чем именно кроссплатформа не подошла.
2Этапы разработки: от брифа до сторов
Здоровый процесс выглядит одинаково у любой зрелой команды:
- Бриф и цели: какую задачу бизнеса решает приложение и по каким метрикам меряем успех.
- ТЗ и смета: зафиксированный объём, сроки и цена до старта разработки, без сюрпризов «в процессе».
- Дизайн и кликабельный прототип: маршруты пользователя можно пощупать до того, как написана первая строка кода.
- Разработка спринтами с демо: каждые одну-две недели вы видите работающий прирост, а не ждёте «чёрный ящик».
- QA и безопасность: тестирование, ревью кода, проверка хранения данных и доступов.
- Публикация в сторы и запуск: аккаунты разработчика, ревью площадок, мониторинг после релиза.
3Из чего складывается стоимость
Цену определяет не «количество экранов», как часто думают, а объём логики за ними. Основные множители: число ролей и сценариев, интеграции (оплаты, push, CRM, ИИ-ассистент), и бэкенд с админкой — серверная часть нередко занимает половину сметы, хотя пользователь её не видит.
Ориентир по рынку заказной разработки: простые приложения начинаются от десятков тысяч рублей, сложные продукты с бэкендом и интеграциями уходят в миллионы. Например, в студии Юнкис мобильная разработка начинается от 70 000 ₽ — точная смета считается после брифа и фиксируется в договоре.
4На чём можно экономить, а на чём нельзя
Можно и нужно: резать скоуп первой версии до ключевого сценария (полноценный MVP-подход), использовать кроссплатформу и готовые компоненты вместо самописных, откладывать «красивое, но не критичное» на вторую итерацию.
Нельзя: на проектировании (ошибки архитектуры всплывают через полгода и стоят дороже всей экономии), на тестировании (падающее приложение убивает рейтинг в сторе быстрее, чем вы успеете его починить) и на юридической стороне — права на исходный код должны передаваться вам по договору, иначе продукт навсегда привязан к подрядчику.
