Когда веб-приложение действительно нужно — и когда нет
Веб-приложение оправдано, когда у процесса есть своя логика, которой нет в готовых сервисах: свои правила расчёта, своя схема согласований, свои роли с разными правами. Или когда данные приходится вручную перекладывать между тремя системами, и на этом регулярно теряются деньги.
И честно про обратную ситуацию: если задача закрывается готовым сервисом за подписку, разработка с нуля — это дороже и рискованнее. Прежде чем брать проект, я смотрю, нет ли готового решения: иногда правильный ответ — настроить существующий инструмент, а не писать свой. Отказаться от лишней разработки дешевле для вас и честнее по отношению к задаче.
Промежуточный вариант, который часто оказывается лучшим: не полноценное приложение, а автоматизация связок между тем, что уже работает. Это дешевле, быстрее и снимает ту же боль. О таком подходе подробнее — в материале про автоматизацию бизнес-процессов.
Почему проект начинается с постановки задачи, а не с дизайна
В приложениях основная стоимость ошибки — не в интерфейсе, а в структуре данных и в правах доступа. Если на старте неверно описано, кто какие данные видит, это всплывает через месяц разработки и переделывается вместе с половиной проекта.
Поэтому первый этап — разбор процесса как он есть сейчас, со всеми исключениями и «а вот в этом случае мы делаем по-другому». Именно исключения обычно и определяют сложность: основной сценарий пишется быстро, а краевые случаи занимают большую часть времени.
Результат этапа — письменная постановка: что делает система, какие есть роли, какие данные хранятся и что происходит в нештатных ситуациях. Только после этого имеет смысл говорить о цене и сроке. Фикс-цена без описанного объёма работ — это не фикс-цена, а отложенный спор.
Цена и почему разброс такой широкий
От 100 000 ₽ — это компактное приложение с одной-двумя ролями, понятным набором экранов и одной внешней интеграцией. Например, личный кабинет клиента с историей заказов и загрузкой документов, или внутренний инструмент, который заменяет разросшуюся таблицу.
Дальше цена определяется количеством ролей, числом сценариев и количеством внешних систем, с которыми нужно обмениваться данными. Каждая новая роль — это не только новые экраны, но и проверка прав в каждой операции. Каждая интеграция — это работа с чужим API, у которого свои лимиты, свои сбои и своя манера ломаться в неудачный момент.
Поэтому по приложениям я не называю цену до разбора задачи. Сумма, названная без вопросов про процесс, — это либо угадывание, либо заявка на доплаты потом. Разбор задачи проводится до подписания договора и ни к чему вас не обязывает.
На чём делаю и что получаете на выходе
Стек: Next.js на фронтенде и серверной части, PostgreSQL для данных. Проверка прав — всегда на сервере, а не только в интерфейсе: интерфейс можно обойти, серверную проверку нельзя.
Развёртывание — на вашем сервере или в вашем облаке, с доступами, оформленными на вас. Данные остаются у вас, и это же снимает вопрос локализации персональных данных в России.
На выходе вы получаете код с документацией, а не чёрный ящик. Это принципиальный момент: проект, который может продолжить только его автор, — это риск для бизнеса, а не преимущество для разработчика.
Как посчитать, окупится ли приложение
Приложение почти никогда не окупается ростом выручки — оно окупается снятием издержек, которые сейчас не видны, потому что размазаны по рабочим часам сотрудников. Поэтому считать нужно не «сколько мы заработаем», а «сколько мы сейчас теряем».
Практический способ: возьмите процесс, который хотите автоматизировать, и посчитайте три числа. Сколько раз в месяц он выполняется. Сколько минут занимает один прогон вручную. Сколько стоит час того человека, который его выполняет. Произведение даёт прямые затраты. К ним добавьте стоимость ошибок: сколько раз за квартал что-то потерялось, ушло не тому клиенту или было посчитано неверно, и во сколько это обошлось.
Дальше сравниваете полученную сумму со стоимостью разработки. Нормальный ориентир для решения — окупаемость в пределах года. Если процесс выполняется дважды в месяц и занимает полчаса, автоматизировать его за 200 000 ₽ смысла нет, и я скажу это прямо. Если он крутится сто раз в месяц и на нём регулярно теряются заказы — считать дальше уже необязательно.
Отдельная категория выгоды, которую сложно посчитать, но нельзя игнорировать: масштабируемость. Процесс на таблицах и переписке перестаёт работать при росте объёма в два-три раза, и обнаруживается это в самый неудобный момент — когда бизнес наконец пошёл вверх.