Смету на приложение проще всего сравнивать по одному числу — итогу внизу. И пока мы смотрим только на эту строку, дешёвая разработка приложения действительно выглядит выгоднее.
Но после запуска начинается жизнь продукта, и часть расходов может оказаться за пределами первоначальной сметы. Не обязательно потому, что подрядчик что-то скрывал: некоторые из них просто не обсудили заранее.
Ниже десять таких строк. Какие-то из них встречаются часто, какие-то зависят от конкретного продукта. Считать их надо до подписания, а не после.
Почему дешёвая разработка приложения оказывается дорогой
Начну с механизма, потому что без него список ниже читается как запугивание.
Если одно предложение заметно дешевле другого, разница из чего-то складывается, и вопрос не в том, честная она или нет, а в том, за счёт чего именно. Проверку я бы начинал с четырёх мест: меньше объём работ, меньше ролей в команде, короче гарантия — или часть работы просто не описана в смете и всплывёт уже в процессе.
Первые три варианта нормальные. Меньший объём за меньшие деньги — это честная сделка, и я сам часто предлагаю начать с малого. Проблема только в четвёртом: когда сумма ниже не потому, что работы меньше, а потому, что её не посчитали.
Отличить одно от другого можно ровно одним способом — посмотреть, что в смете есть, а чего в ней нет. Список ниже как раз про «нет».
Расходы, которые часто появляются после запуска
1. Аккаунты разработчика. Если приложение публикуется в магазинах, понадобятся аккаунты разработчика и связанные с публикацией платежи: у Apple, например, это ежегодный взнос, у Google — разовый. Суммы небольшие и публичные, но проверьте актуальные сами: они меняются. У меня эти платежи перечислены в исключениях; в чужой смете стоит отдельно выяснить, включены они или оплачиваются заказчиком напрямую.
2. Серверы и хостинг. Всё, что не живёт целиком на телефоне, требует сервера: личный кабинет, синхронизация, каталог, история заказов. Если приложению нужен сервер, расходы на инфраструктуру становятся регулярными и сохраняются, пока продукт работает. Размер зависит от нагрузки, архитектуры и выбранной инфраструктуры.
3. Платные тарифы сторонних сервисов. Пуш-уведомления, СМС-коды, карты, аналитика, эквайринг. У каждого своя модель оплаты: фиксированный тариф, цена за запрос или сообщение, бесплатный порог с оплатой сверх него, процент с операции. Проверять поэтому надо не только наличие интеграции, но и тариф после запуска — эквайринг, например, берёт процент с оборота, то есть растёт вместе с вашим успехом.
4. Поддержание совместимости. Эта строка неочевидна, потому что не связана ни с одним вашим решением. Операционные системы обновляются, требования магазинов меняются — и время от времени приходится обновлять зависимости, библиотеки или отдельные функции приложения, чтобы всё продолжало работать. Это не улучшение продукта, а отдельная работа по поддержанию его в строю, и она не бесплатная.
5. Публикация и повторная модерация. Каждое обновление проходит проверку магазина. Если магазин отклоняет обновление, потребуется исправление и повторная подача — это дополнительное время. Первая публикация ещё и требует подготовки: описания, скриншоты, политика конфиденциальности, ответы на вопросы о сборе данных.
Расходы, которые сильнее зависят от конкретного продукта
6. Ошибки после гарантийного срока. Поддержка после запуска входит в работу, но она конечна. У меня, например, в тарифах приложений это один-два месяца в зависимости от формата — исправление ошибок, помощь с публикацией и первыми настройками. Дальше это отдельная работа, и её стоит обсудить заранее: почасово, пакетом или по факту.
7. Изменения на стороне чужих сервисов. Если приложение связано с CRM, 1С, платёжной системой или службой доставки, оно зависит от чужих правил игры. Партнёр обновил свой интерфейс — у вас перестал работать сценарий, хотя вы ничего не меняли. Чем больше интеграций, тем выше шанс однажды это встретить. Заранее стоит выяснить, кто и на каких условиях чинит такие поломки после сдачи: относить их к гарантии на исходную работу или считать отдельной задачей — вопрос договорённости, и лучше решить его до того, как это случится.
8. Контент и наполнение. Разработка создаёт инструмент для работы с каталогом, но сами карточки, описания, фотографии и тексты уведомлений кто-то должен подготовить и загрузить. Это либо ваше время, либо чужая работа за деньги — и на проектах с большим каталогом объём этой работы стоит оценить отдельно, до запуска.
9. Поддержка пользователей. Кто-то отвечает на «не приходит код подтверждения» и на отзывы в магазине. Отзывы видит каждый следующий человек, открывший вашу карточку, — и оставленный без ответа плохой отзыв висит там месяцами.
10. Развитие. После запуска у вас появится список того, чего не хватает: его напишут пользователи. Это не дефекты и не недоделки, а нормальная жизнь продукта — но это новая работа с новым бюджетом. Поэтому полезно ещё до запуска определить, какой бюджет и какой процесс будут у продукта после первой версии.
Сколько стоит разработка приложения, если считать честно
Ответ на этот вопрос всегда состоит из двух частей, а в сметах видна только первая. Цена разработки — то, что вы платите подрядчику. Стоимость владения — то, что продукт просит дальше. Смысл не в том, чтобы напугать десятью строками, а в том, чтобы сравнивать предложения по обеим частям сразу.
Практически это делается так. Возьмите смету и пройдите по списку выше, отмечая три вещи: входит в цену, не входит и стоит денег, не относится к моему случаю. Часть строк отпадёт сразу — офлайн-приложению без сервера не нужен хостинг, продукту без интеграций не грозит пункт 7.
Дальше разделите оставшееся на две группы.
Стартовые: первичная настройка аккаунтов, первая публикация, первое наполнение каталога. Они привязаны к запуску.
Регулярные и периодические: инфраструктура, тарифы сервисов, поддержание совместимости, поддержка пользователей, развитие. Сюда же попадают ежегодные платежи вроде взноса разработчика — заплатить один раз и забыть не получится.
Регулярные расходы легко недооценить: каждый по отдельности выглядит небольшим, но за несколько лет они накапливаются. Поэтому после расчёта первого года полезно посмотреть хотя бы ещё один, более длинный горизонт — приложение живёт дольше двенадцати месяцев, и решение о его судьбе принимается не в декабре первого года.
То, что осталось в средней колонке, и есть разница между ценой в смете и стоимостью владения. Дальше можно честно сравнивать два предложения — и может оказаться, что более дорогое включает часть этих строк, а дешёвое не включает ни одной.
И отдельный вопрос, который стоит задать обоим подрядчикам: что будет через год? Не «есть ли поддержка», а конкретно: кто выпустит обновление под новую версию системы, по какой ставке, с каким сроком реакции.
Где дешевле — это нормально
Было бы нечестно свести всё к «дешёвое всегда плохо». Есть случаи, когда меньшая сумма — правильный выбор.
Объём действительно меньше. Первая версия на один сценарий стоит дешевле полноценного приложения, и это не экономия на качестве, а другой продукт. У меня MVP начинается от 250 000 ₽, полноценное мобильное приложение — от 950 000 ₽, и разница здесь не в старательности, а в составе работ. Подробнее — что входит в разработку MVP приложения и что в неё не входит.
Задача проще, чем кажется. Иногда вместо мобильного приложения нужен веб-кабинет, а вместо него — автоматизация того, что уже есть. Приложение — не единственный способ решить задачу, и самый дорогой из них не всегда лучший.
Подрядчик работает без наценки за процесс. У небольшой команды нет слоя менеджмента, который есть у студии. Это тоже разница в цене, и она честная.
Настораживает другое: когда на вопрос «а это входит?» отвечают «всё включено», но список границ и исключений нигде не показан. У нормальной сметы границы понятны: видно, что входит, а что оплачивается отдельно. У меня границы описаны прямо на странице разработки приложений, рядом с ценами.
Что делать с этим сегодня
Если у вас на руках смета — пройдите по десяти пунктам и отметьте, какие из них в ней описаны. Если ни одного, это не повод отказываться от подрядчика: это повод задать десять вопросов и посмотреть, как он на них отвечает.
Если сметы ещё нет и вы только собираете вводные, полезнее начать с другого конца — с того, что вы хотите проверить первой версией. Пятнадцать вопросов, которые я задаю до оценки, — в разборе технического задания на приложение.
А если хотите взгляд со стороны — пришлите состав работ из своей сметы, суммы можно закрыть. Скажу, что в ней описано, чего в ней нет и какие из десяти строк стоит учитывать именно в вашем случае. Без предложения переделывать: часть ответов вы получите и без меня, и это нормальный результат разбора.