Стоимость кастомной разработки сайта: от чего зависит бюджет

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

Поэтому для кастомной разработки в Guard-IT нет универсального тарифа. Сначала нужно понять, как должна работать будущая система и где проходят границы проекта. После этого появляется рабочая оценка.

В этой статье речь именно о факторах стоимости. Вопрос о том, когда бизнесу вообще нужна кастомная разработка, мы рассматриваем отдельно.

Почему количество страниц почти не показывает стоимость кастомного проекта

Для обычного информационного сайта количество страниц помогает примерно оценить объём работы. Для кастомной системы этого недостаточно.

Представим два проекта с десятью основными экранами.

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

По количеству экранов проекты похожи. По объёму программирования, проектирования и тестирования они различаются значительно.

В кастомной разработке бюджет сильнее зависит от количества правил и связанных сценариев, чем от количества страниц.

Именно поэтому цена такого проекта становится понятной только после разбора его внутренней логики.

Пользовательские роли меняют объём системы

Самый простой сценарий предполагает посетителя и администратора сайта.

Сложнее становится, когда внутри одной системы работают клиенты, дилеры, менеджеры, руководители или другие группы пользователей. У каждой могут быть свои данные, действия и права доступа.

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

С каждым новым уровнем прав появляются дополнительные состояния интерфейса, проверки и правила работы с данными.

На стоимость влияет не само наличие авторизации. Важнее то, что может делать пользователь после входа и насколько его действия связаны с остальной системой.

Бизнес-логика часто формирует основную сложность

Одинаковое действие на экране может запускать совершенно разные процессы.

Обычная заявка сохраняет данные и отправляет уведомление сотруднику. В более сложной системе после обращения может автоматически определяться ответственный, рассчитываться стоимость, проверяться наличие товара, создаваться документ и изменяться статус заказа.

Чем больше условий зависит друг от друга, тем больше вариантов поведения требуется предусмотреть.

Особенно это заметно в конфигураторах, системах расчёта, B2B-порталах и внутренних сервисах. Пользователь видит несколько привычных полей и кнопок, но результат формируется по правилам, которые необходимо реализовать и проверить.

Поэтому фраза «нужен калькулятор» или «нужен кабинет клиента» сама по себе ещё почти ничего не говорит о бюджете.

Интеграции могут отличаться по сложности в разы

Подключение CRM часто указывается одной строкой, хотя внутри неё могут скрываться разные задачи.

В простом варианте форма передаёт имя, телефон и комментарий.

В более сложном проекте сайт получает данные из CRM, отправляет изменения обратно, работает со статусами, товарами, сотрудниками и документами. При этом нужно предусмотреть ситуацию, когда одна из систем временно недоступна или возвращает ошибку.

Та же разница возникает при работе с 1С, ERP, платёжными сервисами, телефонией и внешними API.

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

Дополнительную сложность создают ограничения стороннего сервиса. Если нужные операции его API не поддерживает, задачу приходится решать другим способом или менять первоначальный сценарий.

Структура данных тоже влияет на бюджет

Количество записей в базе само по себе редко определяет сложность проекта.

Гораздо важнее, какие данные связаны между собой.

Простой каталог может состоять из названия, описания, фотографии и цены. В другом проекте товары зависят от характеристик, комплектаций, складов, групп покупателей, документов и индивидуальных условий.

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

Отдельная задача возникает при переносе данных из существующего проекта. Если информация хранится в нескольких системах или имеет разную структуру, её недостаточно просто импортировать. Сначала необходимо определить соответствия и правила переноса.

Административная часть может оказаться отдельной системой

Публичный интерфейс видят клиенты. Но значительная часть кастомного проекта предназначена для сотрудников компании.

Им может потребоваться управление пользователями, заказами, ролями, каталогом, документами, настройками и статусами.

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

Это напрямую влияет на стоимость разработки. Зато после запуска сотрудникам не приходится обращаться к программисту для обычных рабочих действий.

С другой стороны, создавать сложную собственную панель управления без необходимости тоже нерационально. Если типовую задачу нормально закрывает существующая CMS или готовый компонент, разумнее использовать его.

Почему одинаковая функция может иметь разную стоимость

Название функции редко отражает весь объём работы.

Возьмём личный кабинет.

В одном проекте клиент после входа видит свои заявки и контактные данные. В другом доступны индивидуальные цены, несколько организаций, договоры, документы, сотрудники, лимиты и история операций.

Формально в обоих коммерческих предложениях написано «личный кабинет».

Похожая ситуация возникает с каталогами, калькуляторами, поиском, интеграциями и системой управления.

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

Требования к надёжности тоже меняют объём разработки

Не каждой системе нужны одинаковые требования к устойчивости.

Если внутренний сервис используется несколькими сотрудниками и временный перерыв не влияет на важные процессы, архитектура может быть относительно простой.

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

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

Эти требования лучше учитывать на этапе оценки, а не добавлять после того, как основной код уже написан.

Почему дизайн не всегда является главным фактором стоимости

Кастомный проект может выглядеть визуально проще дорогого имиджевого сайта и при этом требовать гораздо большего объёма разработки.

Причина находится в невидимой для посетителя части системы.

После создания интерфейса нужно реализовать его состояния, правила доступа, связь с сервером, работу с данными и внешними сервисами.

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

Это ещё одна причина не оценивать кастомную разработку по внешнему виду макетов.

Почему стоимость нельзя назвать по короткому описанию

Запрос «нужен B2B-портал с личным кабинетом» показывает направление проекта, но ещё не определяет его границы.

Неясно, какие пользователи будут работать в системе, какие действия им доступны, откуда появляются данные и с какими программами должен происходить обмен.

При этом заказчику не требуется самостоятельно проектировать архитектуру или писать техническое задание.

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

Сам процесс перехода от первоначального запроса к смете подробно разобран в отдельной статье об оценке стоимости разработки сайта.

Можно ли уменьшить первоначальный бюджет

Для крупной кастомной системы часто нет смысла сразу реализовывать весь список пожеланий.

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

Например, на первом этапе B2B-порталу могут быть необходимы авторизация, персональный каталог, оформление заявки и документы. Расширенная статистика или дополнительные способы взаимодействия могут появиться позднее.

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

Он не делает весь будущий проект автоматически дешевле. Его задача в другом. Бизнес вкладывает средства в первую очередь в то, что уже необходимо для работы.

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

Что сильнее всего меняет стоимость кастомной разработки

На практике наибольшее влияние обычно оказывают:

• количество пользовательских ролей и различия между ними;

• объём собственной бизнес-логики;

• сложность связей между данными;

• глубина интеграций с внешними системами;

• административные функции для сотрудников;

• перенос информации из существующих систем;

• требования к надёжности и безопасности.

Этот перечень нельзя превратить в универсальный калькулятор. Две интеграции или два личных кабинета сами по себе ничего не говорят о трудозатратах без понимания их логики.

Но он помогает увидеть главное. Кастомная разработка дорожает не из-за самого слова «кастом», а из-за объёма индивидуального поведения, которое требуется спроектировать и реализовать.

Почему у Guard-IT нет фиксированной цены на кастомный проект

Для стандартного формата сайта можно заранее определить примерные границы и показать стартовую стоимость.

У кастомной системы таких стабильных границ нет.

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

Одинаковая стартовая цена для этих проектов была бы слишком условной.

Поэтому Guard-IT сначала разбирает пользователей, процессы, данные, внешние системы и границы первой версии. После этого можно определить состав работ и бюджет.

Если существующая CMS, сервис или готовый компонент закрывают часть задачи без серьёзных ограничений, нет причины разрабатывать эту часть заново.

Что рассказать для первоначальной оценки

На первом разговоре достаточно определить:

• какую задачу должна решать система;

• кто будет ею пользоваться;

• какие основные действия выполняют пользователи;

• с какими сервисами требуется обмен данными;

• есть ли существующие данные или система для переноса;

• что обязательно должно работать в первой версии.

Технические решения, архитектуру и способ реализации должна предложить команда разработки.

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

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

Если вы планируете личный кабинет, B2B-портал, веб-сервис или другую систему со своей бизнес-логикой, опишите Guard-IT текущий процесс и результат, который требуется получить. Мы разберём задачу, определим границы первой версии и подготовим оценку проекта.