Заказать мобильное приложение в Анталье: что определяет стоимость и сроки?
У вас есть идея приложения, и ваш первый вопрос, скорее всего, такой: сколько это стоит и сколько займёт времени? Честный ответ: оба вопроса связаны не с самой идеей, а с её объёмом. Два приложения, описанные одной и той же фразой — «чтобы клиенты могли делать заказы», — могут отличаться по стоимости в разы. Эта статья не даёт прайс-лист; она объясняет, что определяет стоимость и сроки, как сравнивать предложения и о чём нельзя забывать в бюджете первого года.
Сначала определите, к какому типу относится ваше приложение
Больше всего на стоимость влияет не количество экранов, а то, какие операции и от чьего имени выполняет приложение. Четыре ступени ниже надстраиваются друг над другом, и каждая заметно увеличивает объём работы.
- Контентное или каталожное приложение: пользователь просматривает, ищет, сохраняет. Серверная часть относительно проста.
- Приложение с операциями: заказ, запись, бронирование. Появляются отслеживание статусов, уведомления, отмены и сценарии ошибок.
- Платформа для взаимодействия пользователей: две стороны взаимодействуют друг с другом — покупатель и продавец, клиент и мастер, пользователь и пользователь. Возникает потребность в сообщениях, оценках, жалобах и модерации; эту ступень недооценивают чаще всего.
- Внутренний инструмент для бизнеса: публикация в магазинах не нужна, число пользователей известно, но на первый план выходят интеграция с вашими существующими системами и правила доступа.
Если вы отнесёте свою идею к одной из этих четырёх ступеней, полученные предложения станут сопоставимыми. Если вы не уверены, мы можем прояснить это вместе на первой встрече.
Статьи, определяющие стоимость
В предложении на разработку мобильного приложения каждая из перечисленных ниже статей должна быть указана отдельно. Одна строка с цифрой ничего не говорит об объёме работ.
| Статья | Что нужно спросить |
|---|---|
| Серверная часть (backend) | Кто хранит данные, где находится логика операций? Часто здесь больше половины стоимости, и на экранах это не видно. |
| Роли пользователей | Один тип пользователя или уровни вроде «клиент – бизнес – администратор»? Каждая роль — это отдельные экраны и отдельные правила доступа. |
| Панель управления | Откуда вы будете управлять приложением? Если её нет в предложении, приложение даже после запуска невозможно будет администрировать. |
| Интеграции | Оплата, карты, SMS, электронные счета, доставка, ваше текущее ПО. Каждая — отдельная разработка, отдельное тестирование и, как правило, отдельная подписка. |
| Дизайн | Будут использоваться готовые компоненты или разрабатываться фирменный интерфейс? |
| Платформа | Одна платформа или две? Выбор технологии напрямую влияет на эту статью — см. нашу статью native или cross-platform. |
| Объём тестирования | Сколько устройств, сколько сценариев, сколько раундов исправлений включено? |
| Отправка в магазины | Кто отвечает за создание аккаунтов, отправку на публикацию и исправления в случае отклонения, сколько отправок входит в объём? |
| После сдачи | Сколько месяцев поддержки включено, что входит в обслуживание, как оно оплачивается? |
Что удлиняет сроки?
Сроки, которые называют на этапе предложения, — это обычно сроки разработки. А то, что затягивает проект, чаще всего находится за пределами разработки:
- Вопросы, ожидающие решения: если на стороне бизнеса нет человека, принимающего решения, каждый вопрос удлиняет проект.
- Контент и данные: список товаров, тексты, изображения, существующие данные — если они не готовы, запуск ждёт даже после завершения разработки.
- Рост объёма: запросы «а давайте ещё вот это» — самая частая причина задержек. Каждая новая функция помимо разработки добавляет время на тестирование и исправления.
- Одобрения третьих сторон: заявка в платёжную организацию, интеграция электронных счетов или доступ к API не контролируются ни вами, ни разработчиком.
- Проверка в магазинах: её длительность и результат зависят от решения магазинов.
Запрашивая предложение, просите сроки вместе с объёмом работ — письменно и с разбивкой по этапам. Обещание «будет опубликовано к такой-то дате» из-за проверки в магазинах ни один разработчик не может дать в одиночку.
Готово — не значит опубликовано
Между моментом, когда приложение начинает работать, и моментом, когда его можно скачать из магазина, есть отдельный этап. Для App Store и Google Play нужны аккаунты разработчика, и они платные; актуальные тарифы проверяйте на страницах для разработчиков Apple и Google. Мы рекомендуем открывать аккаунты на имя вашей компании — даже если в будущем вы смените подрядчика, приложение, отзывы и история загрузок останутся у вас.
Оба магазина проверяют загруженные приложения и могут их отклонить. Отклонение — не что-то из ряда вон выходящее; требуемые исправления вносятся, и приложение отправляется повторно. С самого начала проясните, кто несёт эту ответственность в проекте и сколько отправок входит в объём работ.
Что забывают в бюджете первого года
Стоимость разработки завершает проект; статьи, которые поддерживают жизнь приложения, — постоянные. Составляя бюджет первого года, учтите и их:
- Аккаунты разработчика в магазинах
- Хостинг сервера и базы данных — растёт вместе с числом пользователей
- Плата за использование сервисов уведомлений, карт, SMS, электронной почты
- Инструменты отслеживания ошибок и мониторинга
- Работы по адаптации к обновлениям операционных систем
- Поддержка пользователей — кто будет отвечать вашим клиентам, пользующимся приложением?
- Продвижение приложения; загрузки не происходят сами по себе
Если бюджет ограничен: сокращайте объём, а не качество
Лучшее, что можно сделать с ограниченным бюджетом, — сократить список функций. Приложение, которое делает одну задачу от начала до конца как следует, и дешевле, и используется чаще, чем приложение, которое делает десять задач наполовину. Решить, что останется за рамками первой версии, важнее, чем решить, что в неё добавить. Подробности этого подхода мы разобрали в статье о проверке идеи с помощью MVP.
Есть и второй вариант: сначала проверить проблему, которую решает приложение, с помощью мобильного веб-интерфейса. Если офлайн-режим, камера, геолокация или уведомления не обязательны, этот путь быстрее и вовсе не затрагивает процесс публикации в магазинах.
Часто задаваемые вопросы
Если я расскажу идею, вы сможете назвать примерную сумму?
За короткую встречу мы можем очертить объём, сказать, на какой ступени вы находитесь и что увеличивает стоимость. А цифра, названная до прояснения объёма, введёт в заблуждение нас обоих.
Могу ли я начать с одной платформы?
Да, и иногда это разумное решение. Если вы знаете распределение устройств у вашей аудитории, можно выпустить первую версию на одной платформе и собрать обратную связь. Технологии с единой кодовой базой упрощают переход на вторую платформу.
Сколько стоят изменения после публикации?
Такие вещи, как контент, цены и акции, можно вынести в панель управления и оставить вам — это бесплатно. Изменения экранов или функций требуют новой версии и проходят проверку в магазинах.
У кого остаётся исходный код приложения?
Это вопрос, который прописывается в договоре; единого стандарта в отрасли нет. Проясните его на этапе предложения — задайте этот вопрос и нам, и каждой компании, с которой ведёте переговоры.
Сначала сайт или приложение?
Если клиенты находят вас через поиск, сайт обычно идёт первым; приложение создаёт ценность, когда есть повторяющееся взаимодействие. Это решение мы подробно разобрали в статье сначала сайт или мобильное приложение.
Давайте вместе определим объём вашей идеи
Расскажите, кто будет пользоваться приложением, какую проблему оно решает и какие функции вы считаете незаменимыми в первой версии; вместе составим объём работ и реалистичный план. Мы общаемся на английском или турецком языке. Ознакомьтесь с нашей услугой разработка мобильных приложений в Анталье и свяжитесь с нами для получения предложения. На что обращать внимание при выборе подрядчика, мы собрали в статье о выборе IT-компании.