Сколько стоит разработка ПО на заказ: из чего складывается цена

Стоимость разработки ПО на заказ складывается из объёма работы: сколько сценариев и платформ нужно, какие интеграции, данные и требования к безопасности, какой срок и кто сопровождает продукт после запуска. Универсальной цены у разработки нет, поэтому честную оценку можно дать только после разбора задачи. Ниже — факторы цены, модели оплаты и то, как подготовиться, чтобы оценка была точнее.

Почему у разработки нет прайс-листа

Вопрос «сколько стоит приложение» похож на вопрос «сколько стоит дом». Ответ зависит от того, что именно строится: бот с одним сценарием, внутренняя система с правами доступа или продукт для нескольких платформ с оплатой и личным кабинетом. Два проекта с одинаковым названием могут отличаться по объёму в разы.

Поэтому цифра без разбора задачи почти всегда вводит в заблуждение. Либо в неё заложен большой запас «на всякий случай», и вы переплачиваете, либо она занижена, и разница всплывает посреди работы в виде допсоглашений. Мы по той же причине не публикуем прайс: сначала разбираем задачу, затем возвращаемся с оценкой и планом по шагам.

Полезнее понимать, из чего складывается цена. Тогда любую оценку, нашу или чужую, можно прочитать осмысленно: что в неё вошло, что нет и где спрятаны риски.

Из чего складывается стоимость: главные факторы

Почти любую оценку можно разложить на несколько факторов. Чем подробнее каждый из них описан на старте, тем меньше неопределённости и запаса в цене.

Обратите внимание: большинство факторов зависит не от технологии, а от решений о продукте. Именно поэтому на цену сильнее всего влияет то, насколько чётко сформулирована задача.

Приложение, бот или ИИ-агент: чем отличается объём

Тип продукта задаёт порядок объёма работы ещё до деталей.

Telegram-бот и небольшая автоматизация

Обычно самый компактный вариант: понятный сценарий, кнопки, обмен данными между двумя системами. Интерфейс уже даёт мессенджер, отдельное приложение публиковать не нужно. Объём растёт, если нужны оплата, мини-приложение или связь с несколькими системами. Подробнее о вариантах — на странице разработки Telegram-ботов.

ИИ-агент на данных компании

Здесь основная работа — не интерфейс, а подключение источников, границы доступа и проверка ответов на ваших реальных примерах. Цена зависит от числа источников, от того, какие действия агент выполняет сам, и от требований к журналу и контролю. Об этом — на странице разработки ИИ-агентов.

Отдельное приложение для нескольких платформ

Самый объёмный вариант: интерфейс под каждую платформу, сервер, хранение данных, публикация в магазинах, подпись и автообновление для настольных версий. Здесь сильнее всего помогает выпуск частями. Подробнее — в разделе о разработке мобильных приложений.

Модели оплаты: фиксированная цена, время и материалы, поэтапно

Кроме объёма, на итоговую сумму влияет то, как договорились считать работу. Основных моделей три.

На практике модели часто совмещают: разбор задачи и первая версия по фиксированной оценке, дальнейшее развитие — по времени или следующими этапами. Главное — чтобы в договоре было понятно, что входит в каждый этап и как согласуются изменения.

Что удорожает разработку

Большая часть лишних расходов появляется не из-за сложности задачи, а из-за того, как устроен проект.

• Всё сразу в первой версии. Каждая второстепенная функция добавляет разработку, проверку и сопровождение, а польза от неё ещё не доказана.
• Решение вместо задачи. Когда заказывают «приложение», хотя проблему закрыл бы бот или автоматизация, платят за лишний объём.
• Размытые требования. Неясности превращаются в переделки, а переделка всегда дороже, чем сделать сразу.
• Изменения без порядка. Если правки приходят в обход согласования, план и оценка теряют смысл.
• Экономия на проверках. Ошибка, найденная пользователями после релиза, обходится дороже той же ошибки, найденной до выкатки.
• Заплатки вместо причин. Код, который чинят сверху, обрастает обходами, и каждая следующая правка стоит дороже.
• Безопасность в конце. Права доступа, хранение секретов и защита данных, добавленные перед сдачей, часто требуют переделки архитектуры.

Как сэкономить без потери качества

Экономить стоит на объёме, а не на качестве. Несколько приёмов, которые снижают стоимость и не создают долгов на будущее:

1. Начните с главного сценария. Первая версия решает одну задачу хорошо, остальное — следующими релизами. Как выбрать этот сценарий, разобрано в гайде MVP: с чего начать.
2. Выбирайте самое простое решение, которое даёт нужный результат. Меньше кода — дешевле строить, быстрее проверять и безопаснее держать в проде.
3. Используйте готовое там, где оно подходит. Типовые части вроде оплаты или рассылок не всегда нужно писать с нуля.
4. Одна кодовая база там, где это выгодно, и родная сборка там, где важна скорость.
5. Принимайте работу частями. Вы видите результат по ходу дела и можете остановить то, что перестало быть нужным.
6. Закладывайте языки и безопасность в архитектуру сразу: потом их добавление обходится дороже.

Стоимость после запуска: о чём забывают

Цена разработки — не вся стоимость продукта. После запуска появляются расходы, которые стоит обсудить заранее:

• серверы и хранение данных;
• аккаунты разработчика в магазинах приложений и сертификаты для подписи настольных версий;
• подписки на внешние сервисы и API, включая модели ИИ, если продукт их использует;
• наблюдение за работой, оповещения о сбоях и резервные копии;
• обновления под новые версии iOS, Android, macOS и Windows и под изменения внешних сервисов;
• исправления и развитие продукта.

Полную стоимость владения удобно сравнивать за несколько лет, особенно если вы выбираете между своей разработкой и подпиской на готовый сервис. Этот выбор подробно разобран в гайде заказная разработка или готовое решение, а варианты сопровождения — на странице поддержки и доработки ПО.

Как подготовиться к оценке

Точность оценки зависит от того, что исполнитель знает о задаче. Готовое техническое задание не обязательно, но несколько вещей стоит описать заранее:

1. Проблема: что мешает сегодня, где теряются деньги и время.
2. Результат: что изменится после запуска и как вы поймёте, что продукт работает.
3. Пользователи и роли: кто работает с продуктом и что каждый делает.
4. Главный сценарий по шагам, своими словами.
5. Платформы и языки, нужные в первой версии.
6. Системы, с которыми нужен обмен данными.
7. Желаемый срок и ориентир по бюджету — не для торга, а чтобы предложить решение, которое в него помещается.
8. Что точно не входит в первую версию.

Как описать задачу подробнее, разобрано в гайде как подготовить ТЗ, а о том, как срок связан с объёмом, — в разборе сроков разработки.

Как мы готовим оценку в JEEKSSHIRE 24

Мы начинаем с задачи, а не с технологии. На разборе смотрим, что мешает бизнесу и какой результат считается успехом. Иногда на этом шаге выясняется, что нужен бот, а не приложение, и это прямо влияет на цену.

Затем предлагаем самое простое решение, которое даёт нужный результат, и раскладываем его на части, которые можно показать и проверить по отдельности. Оценка приходит вместе с планом по шагам: вы видите, что входит в каждую часть, и можете менять приоритеты между ними.

В результат входят работающий продукт, исходный код и права на него, описание того, как продукт устроен и как его выпускать, настроенные оповещения о сбоях и резервные копии. Сопровождение и развитие — по договорённости.

Чтобы получить оценку, опишите задачу в форме на странице разработки. Подробнее о том, что мы делаем, — на странице разработки ПО на заказ.