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