Разработка сайта для бизнеса в 2026 году: как заказать и не переплатить

Собственник открывает вкладку «разработать сайт», вбивает запрос в поисковик и через полчаса тонет в диапазоне цен от 30 тысяч до 3 миллионов рублей за, казалось бы, одну и ту же услугу. Разброс не ошибка рынка, ведь под словом «сайт» скрываются шесть разных продуктов с разной сложностью. Переплата чаще всего случается на этапе постановки задачи еще до того, как открыт хоть один прайс-лист, а торг с подрядчиком тут вторичен.

Главный вопрос в том, какую бизнес-задачу должен закрыть сайт, а цена вторична. Лендинг под рекламную кампанию и корпоративный портал с личным кабинетом — это два разных продукта с разной логикой цены, сроков и рисков. В этой статье мы без маркетингового глянца отвечаем на несколько вопросов. Какой тип сайта нужен бизнесу? Из каких этапов и за какое время делается разработка сайта в 2026 году? Сколько это стоит, как читать смету и выбирать модель оплаты? Какие красные флаги выдают недобросовестного подрядчика и что проверить перед финальной оплатой, чтобы не остаться без доступов к собственному цифровому активу?

Какой сайт нужен бизнесу: лендинг, визитка, корпоративный сайт или интернет-магазин

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

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

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

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

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

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

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

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

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

Из каких этапов состоит разработка сайта

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

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

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

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

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

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

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

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

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

Вопрос сроков задают сразу после вопроса цены, и здесь у рынка на удивление конкретные ответы по каждому этапу отдельно. Сбор требований и планирование занимает от 1 до 5 дней, а прототипирование и дизайн, от 3 до 10 рабочих дней. Верстка и программирование занимают от 5 до 20 рабочих дней в зависимости от сложности функционала. Наполнение контентом растягивается от 1 дня до нескольких недель в зависимости от объема текстов и того, готовы ли материалы у заказчика заранее или их еще предстоит написать с нуля силами студии. Тестирование и запуск обычно укладываются в 1–3 дня, если предыдущие этапы прошли без сюрпризов и переделок в последний момент.

По типу сайта сроки складываются в разную итоговую сумму. Лендинг с товарами делается за 3–7 дней, интернет-магазин на готовом решении, без индивидуальной разработки логики каталога, запускается за 5–10 дней. Кастомный интернет-магазин с уникальной логикой оплаты, доставки и интеграций занимает от 20 дней и дольше. Иногда счет идет на месяцы, если интеграций несколько и каждая требует согласования с внешним сервисом. Разработка сложного проекта, портала или крупного каталога с несколькими ролями пользователей, занимает от 1 до 3 месяцев, и это нормальный срок для проекта такого масштаба с учетом согласований на каждом этапе.

Здесь полезно различать два красных флага, связанных именно со сроками. Первый связан с обещанием запустить сложный проект за неделю. Такое предложение обычно означает шаблон без аналитики и без полноценного брифинга. К реальной скорости работы сильной команды на вашей конкретной задаче оно отношения не имеет. Второй флаг связан с отсутствием подробного технического задания при обсуждении сроков. Если подрядчик называет конкретную цифру без готового ТЗ, эта оценка ничем не подкреплена и с высокой вероятностью изменится в процессе работы, обычно в сторону увеличения. Слишком размытые формулировки сроков без конкретики, «где-то за месяц-полтора», дают тот же сигнал недобросовестности, что и точный, но ничем не обоснованный срок в самом начале переговоров.

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

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

Сколько стоит разработка сайта в 2026 году

По рыночным диапазонам 2026 года лендинг под ключ стоит от 50 000 до 300 000 ₽, сайт-визитка, от 30 000 до 150 000 ₽. Корпоративный сайт стоит куда шире по разбросу, от 120 000 до 3 000 000 ₽. Причина в том, что под одним названием скрывается и сайт на пять страниц с типовым дизайном, и сложный ресурс с личным кабинетом, интеграциями и индивидуальной анимацией. Интернет-магазин обходится в 80 000–2 000 000 ₽ в зависимости от размера каталога и глубины интеграций с 1С или CRM-системой заказчика. Разработка портала или маркетплейса начинается от 2 000 000 ₽ и практически не имеет верхней границы, потому что зависит от количества ролей пользователей и уникальной логики сервисов внутри платформы.

Диапазоны широкие, потому что внутри каждой категории сайт может стоить в 10–20 раз дороже своего младшего аналога в зависимости от того, готовый это шаблон или индивидуальная разработка с нуля. Например, сайт на готовом шаблоне вроде Tilda с минимальной адаптацией под фирменный стиль обойдется в 50 000–80 000 ₽. Корпоративный сайт того же назначения, но с индивидуальным дизайном и версткой с нуля легко перешагнет за 400 000 ₽ при сопоставимом количестве страниц и разделов. Объем реальной работы тут разный, ведь у шаблона дизайн и структура уже придуманы за вас, а у индивидуальной разработки все создается заново под конкретный бренд.

Регион разработки заметно влияет на итоговую цену, и здесь есть две стороны одной медали. По оценке одной цифровой студии, работающей с корпоративными сайтами, простой сайт в Москве стоит от 150 000 ₽, средний по сложности, от 250 000 ₽, сложный проект, от 400 000 ₽. В крупных региональных городах вроде Санкт-Петербурга, Екатеринбурга или Новосибирска разработка выходит на 15–25% дешевле при сопоставимом качестве команды. Но у экономии на регионе есть обратная сторона. В среднем по рынку региональные цены стартуют уже от 90 000 ₽. Вместе с более низкой ценой чаще приходят меньшая экспертиза в сложных нишах, меньше готовых кейсов именно в B2B-сегменте и более долгие сроки согласования из-за меньшего размера команды на проекте.

Отдельно считаются интеграции, которые редко входят в базовую стоимость сайта и почти никогда не попадают в первую озвученную цифру на переговорах. Подключение CRM обходится в 20 000–50 000 ₽, а интеграция с 1С или ERP-системой, 50 000–150 000 ₽ в зависимости от глубины передачи данных. Кастомные API-интеграции с внешними сервисами стартуют от 30 000 ₽, а календарь для онлайн-записи добавляет еще 15 000–25 000 ₽ к смете. Эти суммы редко озвучивают на первой встрече, и именно они превращают привлекательную стартовую цену в счет, который на треть, а иногда и наполовину больше изначально согласованной сметы.

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

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

Из чего складывается смета: по каким этапам считать бюджет

Смета на разработку сайта — это сумма из пяти-семи отдельных статей расходов, и разобраться в ней стоит до подписания договора, то есть до первого счета за незапланированные доработки. Типовое распределение бюджета по этапам выглядит так: аналитика и проектирование забирают 15–25% сметы, дизайн, 20–30%, верстка и фронтенд, 20–25%. Бэкенд и интеграции, самая тяжелая статья, занимают 25–35%, наполнение контентом, 5–10%, тестирование и запуск, 5–10%. Пропорции плавают в зависимости от типа сайта. У интернет-магазина доля бэкенда обычно выше среднего за счет логики каталога и оплаты, а у имиджевого корпоративного сайта, наоборот, растет доля дизайна и визуальной проработки.

Копирайтинг и фотоконтент для наполнения обычно не входят в базовую смету разработки, это отдельная работа, которую заказчику предлагают докупить уже после утверждения основного бюджета на дизайн и верстку. Та же логика касается резерва на правки. Опытные подрядчики закладывают в смету порядка 10–15% от стоимости разработки на доработки после тестирования. Но не все студии проговаривают эту статью на старте, и поэтому заказчик воспринимает такие расходы как внезапную и необоснованную переплату уже после подписания договора.

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

Третья, менее очевидная утечка связана с оплатой за скорость там, где скорость не критична для бизнеса. Срочный тариф студии обычно на 20–40% дороже стандартного, и он оправдан для запуска к конкретной дате, сезонной распродаже или рекламной кампании с фиксированным стартом. Но если жесткого дедлайна нет, переплата за срочность означает деньги, потраченные на скорость, которая бизнесу на самом деле не нужна.

Конструктор, фрилансер, студия или агентство: что выбрать

Четыре варианта исполнителя закрывают одну формальную задачу, но с разной экономикой и разным набором рисков, поэтому цена тут лишь один из критериев сравнения. Конструктор сайтов, самый быстрый и дешевый путь, предлагает тарифы от пары сотен рублей в месяц, а запуск занимает от 1 недели. Взамен клиент получает типовой дизайн в рамках возможностей платформы и общую службу поддержки вместо закрепленного за проектом менеджера, который знает историю именно вашего сайта. У веб-студии логика обратная, запуск идет от 2 недель, зато дизайн произвольный и делается под конкретную задачу бизнеса, а все договоренности фиксируются в договоре с ответственным менеджером на весь срок проекта.

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

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

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

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

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

Как сравнить сметы разных подрядчиков и не запутаться

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

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

Перед тем как подписывать смету, полезно задать подрядчику несколько прямых вопросов и зафиксировать ответы письменно, в переписке или в самом договоре, потому что устным обещаниям менеджера полагаться нельзя. Что именно входит в пункт «наполнение контентом»: только верстка уже готовых текстов заказчика или еще и их написание с нуля силами студии? Сколько бесплатных итераций правок дизайна включено в цену, обычно это 2–5 итераций, и что происходит, когда лимит исчерпан? Правки становятся платными или блокируют переход к следующему этапу? Заложен ли в смету резерв на правки после тестирования, или любое исправление найденной на этом этапе ошибки станет отдельным счетом сверх согласованной суммы?

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

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

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

Какую модель оплаты выбрать, чтобы не переплатить

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

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

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

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

Оплата по времени и материалам, оплата за фактически затраченное время и ресурсы без жесткой привязки к заранее зафиксированной сумме, подходит для сложных сервисов без полного технического задания на старте. Она же годится для MVP-продуктов и проектов с меняющимися требованиями по мере роста понимания задачи. Но модель требует высокого уровня доверия к подрядчику, потому что итоговый бюджет непредсказуем и зависит от вовлеченности заказчика в регулярную проверку отчетов по часам. Адекватность почасового отчета проверяет простое правило. Если студия не может объяснить, что именно делалось в конкретные часы, помимо общей формулировки «программирование», стоит запросить более детальную разбивку до следующей оплаты. Требование стопроцентной предоплаты, такой же признак повышенного риска, как слишком низкая цена и давление на быстрое решение прямо на встрече, вне зависимости от того, какую модель оплаты предлагает подрядчик дальше по тексту договора.

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

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

1. Слишком короткий срок без деталей технического задания. Обещание запустить сложный проект за неделю почти всегда означает шаблон без аналитики, реальной скорости сильной команды на вашей задаче за этим нет.
2. Заниженная стартовая цена «для затравки». Низкая цена в коммерческом предложении обычно означает, что часть работ, тестирование, резерв на правки, необходимые интеграции, не учтена и появится позже отдельным счетом.
3. Договор или техническое задание существуют только на словах. Само по себе устное ТЗ юридической силы не имеет: оно становится значимым только как письменное приложение к подписанному договору.
4. Непрозрачная смета одной строкой. Формулировки «под ключ» и «полный комплект» без построчной расшифровки не дают возможности сравнить предложение с другими и понять, за что именно платит заказчик.
5. Портфолио без рабочих ссылок на реальные сайты клиентов. Недобросовестные исполнители иногда размещают изображения сайтов без их фактической реализации, просто макеты без работающего проекта за ними.
6. Требование стопроцентной предоплаты без разбивки на этапы. Это повышенный риск само по себе, а в сочетании с заниженной ценой и давлением «решайте сегодня, завтра цена вырастет», почти гарантированный сигнал будущих проблем.
7. Недоступность сразу после получения оплаты за очередной этап. Если менеджер резко перестает отвечать сразу после платежа, хотя до этого был на связи в течение часа, дальше вероятны затянутые сроки без внятных объяснений причин.

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

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

Что обязательно должно быть в договоре на разработку сайта

Российское право не выделяет отдельный тип договора «на разработку сайта», поэтому используется либо договор подряда, либо договор возмездного оказания услуг. Выбор конструкции напрямую влияет на защиту заказчика. По статье 779 Гражданского кодекса, договор возмездного оказания услуг обязывает исполнителя оказать услуги по заданию заказчика, а заказчика, соответственно, оплатить эти услуги. Формально оплата здесь не привязана к конкретному материальному результату работы. Договор подряда работает иначе, потому что его целью выступает достижение определенного вещественного результата. Суды чаще квалифицируют разработку сайта именно как подряд, поскольку реальная задача заказчика, получить готовый работающий сайт, а оплата самого процесса его создания этого не покрывает.

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

Обязательный минимум пунктов договора выглядит так. Предмет договора должен точно описывать результат работы со ссылкой на техническое задание как приложение к договору, потому что ТЗ юридической силы не имеет и становится значимым, только если оформлено как подписанное приложение. Сроки нужно разбивать по этапам вместо одной общей даты сдачи всего проекта и закладывать в договор неустойку за просрочку с обеих сторон. Закон не устанавливает размер пени по умолчанию, поэтому стороны сами определяют процент в тексте договора. Обычно это 0,1–1% от суммы этапа за каждый день просрочки. Общую сумму неустойки ограничивают, например не более 5% от стоимости всего договора, чтобы санкция оставалась соразмерной и не становилась отдельным источником конфликта.

Зачем нужен этот пункт, показывает простой пример. Если этап стоимостью 200 000 ₽ задержан на 10 дней при неустойке 0,5% в день, речь идет о 10 000 ₽ компенсации, и простить такую сумму сложнее символической. Без прописанного процента в договоре заказчику пришлось бы доказывать размер реального ущерба от просрочки в суде, что заметно сложнее, чем сослаться на согласованную цифру.

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

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

Еще один обязательный пункт договора касается порядка приемки результата. По статье 720 ГК РФ заказчик обязан немедленно заявить о выявленных недостатках непосредственно при приемке результата. О скрытых недостатках, которые проявились уже позже в процессе использования сайта, он должен известить подрядчика в разумный срок после их обнаружения. Изменения после утверждения ТЗ разумно фиксировать отдельным документом, change-логом с датой, версией правки и описанием того, что именно изменилось и кем согласовано. Такой подход заметно снижает риск переделок и споров уже на финальной приемке проекта, когда обе стороны иначе помнят устные договоренности месячной давности.

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

Кому принадлежит исходный код и кто передает доступы после оплаты

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

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

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

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

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

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

Чек-лист приемки готового сайта перед оплатой финального этапа

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

1. Техника: скорость, устройства, формы. Сайт проверен через Google PageSpeed Insights, протестирован на разных устройствах и в разных браузерах, все формы отправлены тестово с проверкой, что письма действительно доходят на указанный адрес почты. SSL-сертификат установлен и работает на всех страницах без исключения, а страница ошибки 404 корректно настроена вместо стандартной заглушки хостинга.
2. Аналитика: счетчики и поисковые системы. Код отслеживания аналитики стоит на всех страницах сайта, настроены фильтры, исключающие внутренний тестовый трафик команды разработки, а сайт добавлен в Google Search Console, без этого первые недели после запуска пройдут вообще без данных о поведении реальных посетителей.
3. Контент: пустоты, дубли, заглушки. Проверка буквально прогулкой по сайту в роли обычного посетителя: каждая страница из меню открыта и заполнена, пустые разделы, дубли страниц и текстовые заглушки вида «здесь будет ваш текст» обнаруживаются за несколько минут такого обхода.
4. Мобильная версия и реальные жесты. Отдельно от общей адаптивности стоит проверить сайт на реальном телефоне, эмуляция в браузере это не заменит: кнопки должны быть достаточно крупными для пальца, курсору такой размер не нужен, всплывающие элементы не должны перекрывать контент на маленьком экране, меню должно открываться и закрываться без задержек.
5. Изображения и ссылки. Все изображения сжаты без значительной потери качества, у каждого заполнен атрибут alt, а все ссылки на сайте ведут на правильные страницы, без заглушек и несуществующих адресов.
6. Доступы: код, база, домен, хостинг. Перед финальной оплатой заказчик получает исходный код, копию базы данных, макеты дизайна, инструкцию администратора и список подключенных платных сервисов, этот состав фиксируется отдельным актом, устной договоренности в переписке недостаточно.
7. Домен и сторонние сервисы на аккаунтах заказчика. Домен зарегистрирован на компанию заказчика, доступ к панели хостинга выдан отдельно от административной панели CMS, а все сторонние сервисы, от аналитики до платежных систем, подключены через аккаунты заказчика.

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

Еще один совет заключается в том, чтобы не оплачивать финальный этап в тот же день, когда получен доступ ко всем материалам. Разумный срок составляет 3–5 рабочих дней на спокойную проверку по чек-листу выше, без спешки и без давления «оплатите сейчас, доступы придут после». Хороший подрядчик спокойно согласится на такой порядок, а недобросовестный, скорее всего, начнет настаивать на немедленной оплате.

Какие расходы ждут после запуска сайта

Разработка сайта — это разовая инвестиция, но сайт после запуска продолжает требовать регулярных расходов. Часть из них подрядчики не проговаривают на старте проекта, потому что формально это уже не их часть работы. Домен обходится в 800–1500 ₽ в год для стандартной зоны .ru, а премиальные и нестандартные домены могут стоить заметно дороже в зависимости от их коммерческой привлекательности. Хостинг для небольшого сайта стоит порядка 4–8 тысяч рублей в год. Для интернет-магазина под серьезной нагрузкой счет вырастает до 10–60 тысяч рублей в год и выше в зависимости от посещаемости и требований к скорости отклика сервера.

Базовый SSL-сертификат чаще всего идет бесплатно в комплекте с хостингом, но интернет-магазинам нередко требуется более надежный платный сертификат с расширенной проверкой, и это еще 3–5 тысяч рублей в год сверх базового набора. Самая недооцененная статья расходов после запуска, техническая поддержка, и здесь разброс цен велик. По рыночным оценкам, поддержка простых сайтов стоит от 20 до 50 тысяч рублей в месяц. Поддержка сложных проектов с интеграциями и регулярными доработками стоит от 70 тысяч рублей в месяц и выше в зависимости от объема задач и скорости реакции на обращения.

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

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

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

Готовый сайт без дальнейшего продвижения работает как цифровая визитка и каналом привлечения клиентов не становится. Трафик сам по себе просто фактом существования в интернете не приходит, для него нужна отдельная системная работа с поисковой оптимизацией, и ее принципы описаны в материале про продвижение сайта. Если разработка и продвижение изначально закладываются в один бюджет и ведутся одной командой без передачи между разными подрядчиками, это снимает типичный разрыв между «сайт готов» и «сайт начал приводить заявки». Для этого в MarcomHub есть отдельная услуга SEO-продвижения.

Стратегический итог

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

Первый вопрос касается задачи, которую должен закрыть сайт, то есть привлечения заявок, продаж через каталог, имиджевого присутствия в интернете или экосистемы сопутствующих сервисов. Нужно решить, какой тип сайта из разобранных выше реально ей соответствует, а звучание в разговоре с партнерами тут не критерий. Второй вопрос касается бюджета. Какой бюджет реалистичен для этой задачи с учетом самой разработки и годовых расходов на хостинг, поддержку и регулярное наполнение? Сайт без бюджета на жизнь после запуска быстро устаревает и перестает реально работать на бизнес. Третий вопрос касается приемки, то есть того, кто будет принимать готовую работу и по каким конкретным критериям, по техническому чек-листу, срокам из договора или собственному ощущению «выглядит хорошо». Готовы ли вы прописать эти критерии в договоре заранее, до начавшегося спора с подрядчиком?

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