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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дальше идет верстка и программирование: pixel-perfect реализация утвержденных макетов, адаптивная верстка под все устройства от смартфона до широкого монитора, программирование функционала и установка выбранной 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 ₽ при сопоставимом количестве страниц и разделов. Разница не в мошенничестве одной из студий, а в объеме реальной работы: у шаблона дизайн и структура уже придуманы за вас, у индивидуальной разработки все создается заново под конкретный бренд.

Регион разработки заметно влияет на итоговую цену, и здесь есть две стороны одной медали. По оценке одной digital-студии, работающей с корпоративными сайтами, простой сайт в Москве стоит от 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 итераций, и что происходит, когда лимит исчерпан, правки становятся платными или блокируют переход к следующему этапу? Третий: заложен ли в смету резерв на правки после тестирования, или любое исправление найденной на этом этапе ошибки станет отдельным счетом сверх согласованной суммы?

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

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

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

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

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

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

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

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

Time & Material, оплата за фактически затраченное время и ресурсы без жесткой привязки к заранее зафиксированной сумме, подходит для сложных сервисов без полного технического задания на старте, 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 можно начать с бесплатной консультации: разберем задачу вашего бизнеса и посчитаем реалистичный бюджет без завышенных обещаний на старте. А если разработка сайта, только часть более крупной задачи, вывести бизнес в новый канал продаж или перезапустить присутствие компании в интернете целиком, для этого есть услуга комплексного маркетинга, где сайт, продвижение и реклама выстраиваются в одну стратегию, а не работают разрозненно силами разных подрядчиков.