
Приложение отличается от сайта одним неприятным свойством: его нельзя «доделать потом по-тихому». Каждое обновление проходит проверку в магазинах, а пользователи остаются на старых версиях. Поэтому цена ошибки в выборе команды здесь выше.
Коротко
Решите, нужно ли вам вообще приложение или хватит мобильной версии сайта. Если нужно — выбирайте команду по действующим приложениям в магазинах: посмотрите их оценки, дату последнего обновления и отзывы. И заранее договоритесь, кто будет поддерживать продукт после запуска, потому что поддержка здесь обязательна.
Сначала честный вопрос: точно ли нужно приложение
Приложение оправдано, когда им пользуются регулярно и когда нужны возможности телефона: push-уведомления, работа без интернета, камера, геолокация, оплата в одно касание. Классические случаи — доставка, банк, программа лояльности, сервис для повторных заказов.
Если продукт покупают раз в год, приложение почти наверняка не окупится: человек не станет ставить его ради одной покупки. Тогда дешевле и эффективнее вложиться в удобную мобильную версию сайта. Честный подрядчик скажет об этом сам — и это хороший знак, а не потеря заказа.
Нативное или кроссплатформенное
| Подход | Суть | Кому подходит |
|---|---|---|
| Нативная разработка | Отдельно под iOS и отдельно под Android | Сложная графика, игры, активная работа с «железом» телефона, высокие требования к плавности |
| Кроссплатформенная | Один код на обе платформы | Большинство бизнес-задач: каталог, заказы, кабинет, лояльность. Дешевле и быстрее |
| Веб-приложение | Сайт, работающий как приложение | Проверить идею без затрат на магазины |
Для типичного бизнес-приложения кроссплатформенный вариант обычно экономит существенную часть бюджета и времени. Если подрядчик настаивает на нативной разработке, попросите объяснить, что конкретно в вашей задаче этого требует. Внятный ответ есть далеко не всегда.
Как проверять команду
Здесь есть роскошь, которой нет в других услугах: работы подрядчика лежат в открытых магазинах приложений. Пользуйтесь этим.
Скачайте и попробуйте. Два-три приложения из портфолио — установите и пройдите основной сценарий. Впечатление от живого продукта не заменит презентация.
Посмотрите оценки и отзывы. Особенно жалобы: на что ругаются — на бизнес-модель заказчика или на вылеты и тормоза.
Проверьте дату обновления. Приложение, не обновлявшееся два года, скорее всего заброшено. Спросите, продолжается ли сотрудничество.
Уточните, кто разработчик в карточке. Иногда выясняется, что подрядчик участвовал в проекте частично.
Что должно быть в предложении
Помимо самой разработки в смете обязаны быть строки, о которых новички забывают: дизайн под обе платформы, серверная часть и админка (приложение почти всегда требует бэкенда), тестирование на реальных устройствах разных размеров, публикация в магазинах и сопровождение проверки, аккаунты разработчика и их ежегодная стоимость.
Отдельно спросите про аналитику и сбор ошибок. Без них вы не узнаете, где пользователи бросают процесс и почему приложение вылетает.
Аккаунты в магазинах — только на вас
Аккаунты разработчика в магазинах приложений регистрируются на вашу компанию, подрядчику даётся доступ как участнику. Если приложение опубликовано под аккаунтом агентства, оно фактически принадлежит агентству: вы не сможете ни обновить его, ни передать другой команде без их участия.
Это же касается исходного кода, доступа к серверу, базы данных и ключей подписи. Ключ подписи потерять особенно неприятно — без него обновить приложение невозможно, придётся публиковать новое и терять всех пользователей.
Поддержка — не опция
Приложение нельзя запустить и забыть. Операционные системы обновляются дважды в год, магазины меняют требования, старые версии перестают работать. Приложение без поддержки перестаёт запускаться примерно за год-полтора.
Поэтому договор о поддержке обсуждается до начала разработки, а не после. Заложите её в бюджет сразу — иначе через год получите неприятный сюрприз и продукт, который нельзя обновить.
Как снизить риск
Не заказывайте сразу большой продукт со всеми функциями. Разумный путь — сначала минимальная версия с одним ключевым сценарием, запуск, сбор реальной обратной связи, потом развитие. Так вы проверите и саму идею, и команду на небольшой сумме.
Второй приём — разбить оплату по этапам с приёмкой каждого: прототип, дизайн, работающая версия для тестирования, публикация. Платить всё вперёд не стоит.
Что делать дальше
Опишите основной сценарий пользователя — что человек делает в приложении от запуска до результата, — и с этим идите к подрядчикам. Кандидатов смотрите в разделе разработки приложений; если проект игровой, вам в геймдев-студии. Задание оформите по шаблону брифа, а перед подписанием проверьте команду по чек-листу и посмотрите, что должно быть в договоре.