Сколько стоит создание сайта: как читать смету, а не одну цифру

Разделите стоимость сайта на три бюджета

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

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

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

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

Переведите задачу в единицы оценки

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

Удобнее считать проект по единицам результата:

1. Типы страниц, а не общее число URL.
2. Уникальные пользовательские сценарии.
3. Компоненты и состояния интерфейса.
4. Единицы контента, которые нужно создать или переработать.
5. Интеграции с внешними системами.
6. События и отчеты аналитики.
7. Роли администрирования и согласования.
8. Критерии приемки.

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

Отделите обязательный контур от развития

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

Я предлагаю делить объем на три очереди:

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

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

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

Зафиксируйте, кто готовит каждый исходный материал

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

Для каждого вида исходных данных нужно назначить владельца и состояние.

Если в коммерческом предложении написано «контент предоставляет заказчик», это еще не означает нулевую стоимость. Нужно понять, в каком виде он передается, кто проверяет полноту, адаптирует к структуре, загружает в CMS и отвечает за задержку. Иначе готовность материалов превращается в спор уже после старта.

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

Читайте смету по результатам, а не профессиям

Строки «дизайн», «frontend», «backend» и «тестирование» описывают участников, но не сообщают, что получит заказчик. Смета становится управляемой, когда каждая крупная строка отвечает на четыре вопроса:

1. Какой результат создается.
2. Что входит в результат.
3. Как он принимается.
4. Что считается изменением объема.

Такой формат полезен обеим сторонам. Заказчик видит границы покупки, подрядчик защищен от бесконечного расширения задачи фразой «мы думали, это входит».

Посчитайте цену неопределенности отдельно

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

Обычно неопределенными остаются:

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

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

Зрелая смета не делает вид, что неизвестного нет. Она показывает, где оно находится, кто его снимает и какое решение изменит бюджет.

Приведите предложения к одному масштабу

Чтобы сравнить подрядчиков, перенесите предложения в общую таблицу. Неуказанную работу нельзя считать включенной или бесплатной. Ее статус - «нужно уточнить».

Проверьте восемь контуров:

1. Исследование и постановка задачи.
2. Структура и прототипы.
3. Подготовка контента.
4. Дизайн и адаптивные состояния.
5. Разработка и CMS.
6. Формы, аналитика и интеграции.
7. Тестирование, перенос и запуск.
8. Поддержка, гарантированный период исправлений и дальнейшие изменения.

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

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

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

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

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

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

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

Свяжите график платежей с приемкой

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

У проекта должны быть контрольные точки, после которых обе стороны одинаково понимают состояние работы:

1. Зафиксированы объем, роли и требования.
2. Приняты структура и прототипы.
3. Принята дизайн-система и ключевые шаблоны.
4. Реализован рабочий контур.
5. Пройдены тестовые сценарии и устранены критические дефекты.
6. Выполнены запуск и передача доступов.

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

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

Где можно сократить бюджет

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

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

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

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

Как Медиакод оценивает разработку сайта

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

В работе участвуют сертифицированные специалисты по Bitrix, Tilda, Яндекс Директу, Метрике, VK Рекламе, Telegram Ads и SMM, а также frontend- и backend-разработчики. Подтверждения собраны в разделе сертификаций. Победы, финалы и позиции Медиакод в топ-5 профессиональных премий зафиксированы в разделе наград.

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