«Под ключ» — самое популярное слово в описаниях разработки и самое неопределённое.
Формально оно означает, что заказчику не придётся ничего доделывать самому: он получает работающий продукт, а не набор файлов. На практике разработка мобильных приложений под ключ означает у разных подрядчиков очень разный объём работы — и разница обнаруживается не при подписании, а через несколько месяцев, когда выясняется, что публикация в сторах или серверная часть считаются отдельно.
Поэтому разберу предметно: из каких этапов состоит разработка мобильного приложения, что заказчик получает на выходе каждого, сколько это занимает и что в «под ключ» обычно не входит — ни у меня, ни у большинства адекватных подрядчиков.
Статья про полноценный продукт для iOS и Android. Если вы ещё выбираете формат запуска, начните с разбора трёх сценариев и их бюджетов — там видно, нужен ли вам сейчас полный проект или достаточно первой версии.
Что на самом деле значит «под ключ» — и как проверить это одним вопросом
Создание мобильных приложений под ключ обещают почти все — вопрос только в том, что каждый вкладывает в это слово. Проверяется оно одним вопросом.
Когда подрядчик говорит «делаем под ключ», спросите: что именно я получу в конце каждого этапа?
Не «что вы будете делать» — это вам расскажут охотно. Именно что вы получите: файл, доступ, сборку, документ. Работа, у которой нет предъявляемого результата, не проверяется никак, а значит, и не считается сделанной или несделанной — её просто нельзя обсуждать.
Дальше по каждому этапу я называю такой результат.
Этап 1. Разбор задачи: с чего начинается разработка мобильного приложения
Здесь ещё нет ни экранов, ни кода. Разбираются цели бизнеса, главные сценарии, роли пользователей и то, с какими системами приложение должно обмениваться данными.
Звучит как формальность, но именно на этом этапе определяется бюджет. И именно здесь разработка мобильных приложений для бизнеса расходится с приложениями «для людей»: у бизнеса почти всегда несколько ролей. Приложение, где пользователь один, стоит принципиально иначе, чем приложение, где есть клиент, менеджер и курьер: у каждой роли свои экраны, права и сценарии, и это фактически несколько приложений внутри одного проекта.
Что вы получаете на выходе: описание сценариев и ролей — то есть согласованный ответ на вопрос, что именно приложение должно уметь в первой версии. Из этого документа дальше растёт всё остальное, включая смету.
Здесь же решается, нужно ли вам полноценное приложение вообще. Если идея ещё не проверена на пользователях, честнее начать с MVP — первой версии с одним главным сценарием, — а к полному продукту вернуться, когда спрос подтверждён. Разница в бюджете кратная, и я говорю об этом до начала работ, а не после.
Этап 2. Проектирование и дизайн экранов
Сначала структура: какие экраны есть, как человек между ними ходит, что видит после каждого действия. Потом — дизайн под iOS и Android.
Порядок здесь важнее, чем кажется. Пока это схема, перестановка шага стоит получаса. Та же правка после разработки задевает интерфейс, серверную логику и данные, а иногда и то, что уже протестировано.
Что вы получаете на выходе: структуру приложения, которую можно пройти как пользователь, и макеты всех экранов. Не «примерное представление» — конкретные экраны, по которым видно, как продукт будет выглядеть в руках.
Этап 3. Разработка мобильного приложения и интеграции
Самая объёмная часть, и в ней происходит то, чего не видно на макетах: данные начинают сохраняться и загружаться, оплата — проходить, push-уведомления — приходить, а внешние сервисы — обмениваться информацией с приложением.
В большинстве случаев я делаю одно кроссплатформенное приложение, которое работает и на iOS, и на Android из общей кодовой базы: это дешевле в разработке и заметно дешевле в поддержке, потому что правка вносится один раз, а не дважды. Нативная разработка нужна при особых требованиях к производительности или к возможностям устройства — это обсуждается отдельно и стоит иначе.
Что вы получаете на выходе: работающие сборки, которые можно установить на телефон и потрогать руками ещё до окончания проекта. Не отчёт о проценте готовности — само приложение в том состоянии, в котором оно есть.
Этап 4. Тестирование, публикация и поддержка
Приложение проверяется как единый продукт, а не по экранам: пользовательский путь целиком, на реальных устройствах, включая ошибочные ситуации. Многие проблемы живут на стыках и по отдельным экранам не видны вовсе.
Дальше — публикация в App Store и Google Play: сборки, иконки, описания, прохождение модерации. Модерация — отдельная работа со своими правилами, и она входит в проект.
Что вы получаете на выходе: приложение в сторах, доступное вашим пользователям, и поддержку после релиза. Обновляются iOS и Android, меняются внешние сервисы, появляются устройства и сценарии, которых не было на тестах, — продукт после запуска не замирает.
Один важный момент про права: аккаунты разработчика Apple и Google оформляются на вас, а не на подрядчика. Оплачиваются они отдельно, зато приложение остаётся вашим — и, если вы когда-нибудь смените исполнителя, это не превратится в проблему.
Сколько времени занимает разработка мобильных приложений
Скажу честно: точный срок разработки мобильного приложения до разбора задачи назвать нельзя, и подрядчик, который называет его по одной фразе «нужно приложение для бизнеса», называет его наугад.
Ориентир по полноценному приложению — несколько месяцев. MVP с одним главным сценарием — ориентировочно несколько недель. Разброс внутри этих рамок задаёт не размер компании и не количество экранов, а три вещи:
- число ролей. Клиент, менеджер, курьер, администратор — у каждого свои экраны и права;
- интеграции. Разобраться в чужой системе, её ограничениях и способе синхронизации занимает больше времени, чем написать код на своей стороне. Наличие API — только половина дела;
- требования к данным. Персональные, финансовые и медицинские данные означают повышенные требования к хранению, доступу и архитектуре.
Что сокращает срок хуже, чем кажется: увеличение числа людей на проекте. Что сокращает реально — уменьшение объёма первой версии.
И ещё одно, о чём редко предупреждают: часть срока проекта вам не принадлежит. Модерация в сторах идёт по своему расписанию, а согласования на стороне заказчика — по своему. Поэтому в разговоре про сроки я всегда отделяю работу от ожидания.
Что входит в стоимость разработки мобильных приложений
Полноценное мобильное приложение для iOS и Android стартует от 950 000 ₽. В эту сумму входит:
- разбор задачи, сценариев и ролей;
- проектирование структуры и пути пользователя;
- дизайн экранов под iOS и Android;
- разработка кроссплатформенного приложения;
- личный кабинет, записи или заказы;
- интеграция с действующей CRM или серверной частью;
- тестирование на реальных устройствах;
- подготовка к публикации в App Store и Google Play.
Почему одна и та же задача у разных подрядчиков стоит и 250 000, и 950 000 ₽ — это отдельный разговор, и он разобран здесь по трём сценариям запуска.
А что не входит
Это самая полезная часть текста, и её обычно не пишут.
Отсутствие пункта в смете не означает, что работы не будет. Оно означает, что за неё выставят счёт позже. У меня оценивается отдельно:
- создание серверной части и админ-панели с нуля — если их ещё нет. В админке нередко больше экранов, чем в пользовательской части, и считать проект только по тому, что видит клиент, — главная причина недооценки бюджета;
- нестандартная бизнес-логика — расчёты, правила и алгоритмы, специфичные для вашего бизнеса;
- сложные интеграции и перенос данных из существующих систем;
- нативная разработка под особые требования;
- аккаунты разработчика Apple и Google — оформляются на вас;
- платные внешние сервисы: карты, рассылки, тарифы сторонних API.
Ни один из этих пунктов не является подвохом — все они есть в любом проекте у любого подрядчика. Разница только в том, названы они до старта или после.
Поэтапная оплата — и почему это важнее, чем скидка
Я работаю по этапам с поэтапной оплатой. Это не любезность, а способ распределить риск: вы не отдаёте весь бюджет за продукт, которого ещё не видели, а платите за этап, результат которого можете посмотреть.
У этого есть следствие, которое стоит понимать заранее: процесс требует вашего участия. Нужно смотреть промежуточный результат, отвечать на вопросы и принимать решения. Заказчик, который говорит «делайте, покажете в конце», выключает единственный работающий механизм контроля — и возвращается к той самой ситуации, когда впервые видит продукт в день сдачи.
Когда «под ключ» не нужно
Полноценное мобильное приложение — не всегда правильный первый шаг.
Если спрос ещё не подтверждён, разумнее проверить идею на MVP. Если пользователи работают за компьютером, а не с телефона, задачу может закрыть веб-приложение или личный кабинет — дешевле и быстрее. А иногда достаточно сайта с онлайн-записью, и разработка мобильного приложения оказывается дорогим ответом на вопрос, который решается проще.
На разборе я говорю об этом прямо, даже когда это уменьшает проект: заказчик, которому продали лишнее, всё равно это поймёт — просто позже и с худшим отношением к подрядчику.
Подробнее про формат полноценного продукта — на странице разработки мобильных приложений. Там же — реальный проект, состав работ и частые вопросы перед заявкой.