Сколько на самом деле стоит сайт за 3 года: полная стоимость владения

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

С сайтами бизнес почему-то нередко рассуждает иначе.

Компания заказывает сайт за 150 000 ₽ и считает, что примерно столько цифровой актив и стоил. Иногда особенно повезло: знакомый студент сделал за 15 000 ₽, домен стоит несколько сотен рублей, SSL бесплатный, а значит ближайшие три года почти ничего платить не придётся.

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

Ни одна из этих ситуаций не делает первоначальную цену разработки неправильной.

Просто стоимость создания сайта и стоимость владения сайтом — разные числа.

Для оценки второго используется понятие TCO — Total Cost of Ownership, полная стоимость владения. В IT этот показатель обычно включает не только приобретение системы, но и расходы на управление, поддержку, труд людей, простои и другие издержки на протяжении срока эксплуатации. Именно так TCO определяет, например, FinOps Foundation.

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

Сколько стоит сделать сайт?

А ещё и так:

Сколько будет стоить нормально пользоваться этим сайтом следующие три года?

Что такое TCO сайта простыми словами

Для сайта можно использовать довольно простую модель:

TCO = создание + эксплуатация + обслуживание + необходимые изменения + косвенные расходы

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

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

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

Базовый технический TCO

Это деньги, необходимые, чтобы сайт продолжал существовать, нормально работать и оставаться управляемой системой:

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

Стоимость развития продукта

Сайт может работать технически идеально, но бизнес изменился.

Появились новые услуги, города, товары, интеграции, способы оплаты, пользовательские сценарии.

Тогда возникают расходы на:

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

Это уже не просто «поддержать сайт живым», а адаптировать его к изменению бизнеса.

Маркетинг и привлечение клиентов

SEO, реклама, производство контента, CRO и другие способы получения клиентов лучше считать отдельным слоем.

Технически сайт способен существовать без SEO.

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

Такое разделение защищает от двух противоположных манипуляций.

Первая:

сайт стоит всего 500 ₽ в месяц, потому что именно столько стоит hosting.

Вторая:

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

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

Начинаем с цены разработки — но на ней не заканчиваем

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

В неё могут входить:

• анализ задачи;
• проектирование структуры;
• прототипы;
• дизайн;
• frontend;
• backend;
• CMS;
• импорт данных;
• интеграции;
• настройка аналитики;
• тестирование;
• запуск.

Но уже здесь полезно отказаться от мифа:

дешёвый сайт обязательно плохой, дорогой обязательно хороший.

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

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

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

Например, разработчик сэкономил время так:

• нет нормального Git;
• всё написано в одном файле;
• контент невозможно менять без программиста;
• интеграция сделана вручную «на сейчас»;
• нет staging;
• нет резервного сценария;
• установлено несколько десятков плагинов с пересекающимися функциями;
• никто не документировал нестандартные решения.

Первый счёт стал меньше.

Будущая стоимость каждой правки — больше.

Это уже экономическая характеристика архитектуры.

Домен: маленькая сумма, которая хорошо объясняет принцип TCO

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

На 15 октября 2026 года Timeweb указывает для .ru регистрацию от 179 ₽, а продление — 399 ₽ в год.

Если предположить, что тариф не изменится, три года выглядят так:

179 + 399 + 399 = 977 ₽

Не огромные деньги.

Но это уже не рекламная стоимость первого года.

Та же логика распространяется на более дорогие повторяющиеся услуги.

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

SSL: вполне может стоить ноль

Расчёт стоимости сайта легко раздуть ненужными обязательными расходами.

SSL — хороший пример.

Let’s Encrypt является некоммерческим центром сертификации и выдаёт бесплатные TLS-сертификаты. Автоматизация позволяет использовать HTTPS без ежегодной покупки обычного DV-сертификата.

Поэтому строка:

SSL — обязательно 5 000–15 000 ₽ в год

для типичного корпоративного сайта неверна.

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

Для обычного WordPress стоимость самого TLS-сертификата вполне может быть:

0 ₽.

При этом его корректное продление и настройка всё равно являются частью эксплуатации.

Бесплатный сертификат не означает бесплатное администрирование любой инфраструктуры.

Hosting за 200 ₽ и сервер за несколько тысяч — оба варианта реальны

Фраза:

содержание сайта стоит несколько сотен рублей в месяц

может быть совершенно правдивой.

Например, текущие тарифы Рег.ру для обычного shared hosting начинаются от нескольких сотен рублей в месяц: PHP-поддерживающий Host-A указан по цене 330 ₽/мес при помесячном тарифе, а на длинном периоде стоимость ниже. Провайдер включает SSL, резервные копии и ряд инфраструктурных функций.

Beget сейчас показывает виртуальный hosting от 420 ₽/мес при годовой оплате, а VPS — от 510 ₽/мес.

Для сайта услуг этого может быть совершенно достаточно.

Но из этого нельзя вывести универсальное правило:

любой сайт должен стоить 500 ₽ в месяц.

Посмотрим на другой класс инфраструктуры.

Timeweb Cloud для московского региона на момент проверки показывает, например:

• 1 GB RAM / 15 GB NVMe — 1 920 ₽/мес;
• 2 GB / 30 GB — 3 000 ₽/мес;
• 4 GB / 50 GB — 5 480 ₽/мес.

Если проект действительно требует конфигурации за 3 000 ₽ ежемесячно и стоимость не изменится, за три года только эта строка даст:

3 000 × 36 = 108 000 ₽

Причём cloud-инфраструктура крупного проекта может дополнительно включать:

• managed database;
• object storage;
• CDN;
• публичные IP;
• backups;
• load balancer;
• monitoring;
• traffic;
• DDoS/WAF.

Сам Timeweb Cloud, например, отдельно тарифицирует публичный IP, DDoS-защиту и автоматические резервные копии в некоторых конфигураторах.

То есть вопрос звучит не так:

Сколько должен стоить hosting?

А:

Какая инфраструктура действительно требуется именно этому проекту?

Резервные копии — не просто ещё один архив

У простого shared hosting backup может уже входить в тариф.

Рег.ру, например, заявляет хранение 30 резервных копий на части текущих hosting-тарифов, а Beget включает автоматические backups в VPS-инфраструктуру.

Но для более серьёзного проекта фраза:

бэкапы есть

слишком короткая.

Нужно понимать:

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

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

Технически что-то внутри есть.

Узнать, насколько оно полезно, хотелось бы до аварии.

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

WordPress бесплатный. WordPress-сайт — необязательно

WordPress core распространяется как open-source ПО.

Это действительно позволяет не платить лицензию за саму CMS.

Но вокруг WordPress может сформироваться целый набор ежегодных subscriptions:

• custom fields;
• page builder;
• multilingual;
• фильтрация;
• backup;
• security;
• image optimization;
• SMTP;
• search;
• WooCommerce extensions;
• формы.

Например, ACF PRO сейчас стоит:

• Personal — $49/год;
• Freelancer — $149/год;
• Agency — $249/год.

Для одного сайта Personal при неизменной цене за три года:

$49 × 3 = $147

Не катастрофа.

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

Elementor также работает по ежегодной подписной модели; его актуальная документация прямо указывает paid plans и annual subscription, а, например, текущий checkout для Advanced на три сайта показывает $108/год с автоматическим продлением.

Именно поэтому при покупке сайта полезно спрашивать не:

Какие плагины установлены?

А:

Какие из них требуют регулярной оплаты и кому принадлежат подписки?

«Плагин уже стоит» не означает, что будущих расходов нет

Представим, студия передала WordPress-сайт.

ACF PRO установлен.

Elementor установлен.

Формы работают.

В первый год всё оплачено через агентские лицензии.

В договоре ничего про это нет.

Через год сотрудничество заканчивается.

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

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

Это отличный пример скрытого TCO:

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

Именно поэтому хороший handover должен включать список:

компонент → лицензия → аккаунт → срок → цена продления → последствия непродления

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

Техническое обслуживание — это не разработка новых функций

Очень важно не смешивать две разные работы.

Представим WordPress-сайт, на котором год вообще не появляется новых функций.

Это не значит, что технических задач нет.

Периодически могут потребоваться:

• обновление WordPress;
• обновление темы;
• обновление plugins;
• совместимость с новой PHP;
• контроль базы;
• проверка cron;
• очистка логов;
• контроль SSL;
• проверка форм;
• резервные копии;
• устранение уязвимости;
• проверка внешней интеграции.

Это maintenance.

А запрос:

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

— development.

Разделять их полезно и финансово.

Иначе заказчик видит ежемесячную поддержку и думает:

Мы платили год, а новых разделов почти не появилось.

А подрядчик отвечает:

Мы весь год поддерживали систему.

Оба могут быть правы.

Просто в договоре две разные экономические задачи назвали одним словом «работы по сайту».

На Vagizov.com признаки, по которым проекту уже требуется именно техническое сопровождение, я отдельно разбирал в материале «Признаки, что сайту уже нужна техническая поддержка».

Самый дешёвый сайт: 15 000 ₽ и три года эксплуатации

Теперь вернёмся к обещанному сценарию.

Компания нашла студента.

Тот сделал небольшой WordPress-сайт за:

15 000 ₽.

Никакого подвоха.

Проект действительно работал.

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

Первый платёж

Разработка:

15 000 ₽

Пока всё выглядит прекрасно.

За три года

Допустим, произошли следующие вполне обычные события:

Расход	Сумма
первоначальная разработка	15 000 ₽
домен и hosting за 3 года	18 000 ₽
ремонт формы после обновления	12 000 ₽
исправление мобильной версии	25 000 ₽
настройка backup и базовой безопасности	18 000 ₽
конфликты plugins/PHP во втором году	30 000 ₽
небольшие изменения контента и структуры	24 000 ₽
вынужденная миграция	35 000 ₽
частичная переделка старой темы	80 000 ₽
Итого за три года	257 000 ₽

Сайт всё ещё можно честно назвать:

сайт за 15 000 ₽.

И это будет правда.

Просто его трёхлетний TCO в нашем модельном сценарии — 257 000 ₽.

Теперь возникает соблазн сделать неправильный вывод:

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

Не обязательно.

Проект за 200 000 ₽ тоже мог получить те же проблемы, плюс более дорогую поддержку.

Правильный вывод другой:

Цена разработки ничего не говорит о будущей поддерживаемости без знания архитектуры.

Если сайт за 15 000 ₽ был аккуратно собран под простую задачу и три года практически не менялся, его TCO мог остаться очень низким.

Если сайт за 500 000 ₽ был спроектирован плохо, высокая цена не спасёт его от технического долга.

Сколько стоит «ничего не делать»

Есть ещё одна крайность.

Раз обслуживать сайт дорого, можно ничего не обслуживать.

Тогда год выглядит великолепно:

техподдержка = 0 ₽

Второй тоже может пройти спокойно.

А затем:

• устаревший plugin конфликтует с PHP;
• форма перестаёт отправлять заявки;
• backup оказывается годичной давности;
• сайт заражается;
• hosting требует перехода на новую среду;
• новый разработчик сначала три дня разбирается, почему обновлять ничего нельзя.

Получается интересная бухгалтерская иллюзия.

Расходов действительно не было.

Они просто не исчезли, а переместились во времени и стали менее предсказуемыми.

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

Первые годы цифры прекрасные.

Потом появляется другой тип счёта.

Безопасность: не покупаем страх, а оцениваем критичность

Разговор о TCO легко превратить в запугивание:

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

Так писать не нужно.

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

Соответственно, могут различаться и расходы на:

• мониторинг;
• резервирование;
• WAF;
• аудит;
• контроль изменений;
• incident response.

Правильный вопрос:

Сколько стоит разумный уровень защиты относительно ценности и критичности системы?

На небольшом сайте часть задач может закрываться hosting-провайдером и аккуратным обновлением CMS.

У серьёзного сервиса безопасность уже становится отдельным эксплуатационным процессом.

Мониторинг: главная страница 200, а продажи всё равно стоят

Простейший uptime-monitor проверяет:

GET /

и радуется ответу:

200 OK

Для сайта-визитки этого иногда достаточно.

Для интернет-магазина — нет.

Главная может отвечать 200, пока:

• checkout падает;
• платёжная система не отвечает;
• CRM не получает заказ;
• поиск товаров сломан;
• доставка не рассчитывается.

Поэтому стоимость мониторинга тоже должна соответствовать бизнес-сценарию.

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

Доставка писем и корпоративная почта

Небольшой hosting способен включать почту прямо в тариф.

Например, Timeweb в текущих shared-hosting планах заявляет почтовую квоту и бесплатный SSL внутри тарифа.

Для простого сайта это может закрыть потребность полностью.

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

• transactional SMTP;
• отдельную корпоративную почту;
• большие объёмы отправки;
• email API;
• мониторинг delivery.

И ещё одна «мелкая» подписка превращается в строку TCO.

В отдельности почти все такие расходы выглядят небольшими.

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

Содержание сайта тоже стареет

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

Компания изменила цены.

Сменился директор.

Появился новый филиал.

Закрылась услуга.

Добавились сотрудники.

Изменились фотографии.

Появились новые кейсы.

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

Поэтому обновление контента я бы относил не к минимальной стоимости «держать сервер включённым», а к business TCO — стоимости использования сайта как нормального рабочего инструмента.

Сам бизнес меняется — и сайт приходится менять вместе с ним

Представим строительную компанию.

Первоначально она занималась только ремонтом квартир.

Через год добавила дизайн интерьеров.

Ещё через год стала строить загородные дома.

Потом понадобились:

• новые разделы;
• калькулятор;
• портфолио другого типа;
• CRM;
• новые формы;
• отдельная структура заявок.

Сайт не сломался.

Он просто перестал полностью соответствовать компании.

Это важное отличие.

Не все будущие расходы являются следствием плохой разработки.

Часть из них означает, что бизнес развивается.

Хорошая архитектура не отменит такие расходы.

Она сделает их более предсказуемыми.

Интеграция тоже не живёт вечно

При запуске сайт связали с CRM.

Потратили деньги.

В смете поставили галочку:

интеграция — готово.

Но API имеет собственный жизненный цикл.

Могут измениться:

• методы авторизации;
• endpoint;
• формат данных;
• обязательные поля;
• лимиты;
• webhook;
• версия CRM;
• платёжный API;
• служба доставки.

Поэтому интеграция — не всегда одноразовый asset.

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

Время сотрудников тоже стоит денег

Это одна из самых недооценённых строк TCO.

Допустим, интернет-магазин не имеет нормальной интеграции с учётной системой.

Менеджер вручную переносит часть информации.

Всего:

4 часа в месяц.

За три года:

4 × 36 = 144 часа

Если стоимость рабочего часа сотрудника для бизнеса условно составляет 1 000 ₽, получаем:

144 × 1 000 = 144 000 ₽

Теперь представим, что автоматизация стоит 80 000 ₽.

В первоначальной смете интеграция увеличивает цену проекта.

В трёхлетней модели она уже выглядит совершенно иначе.

Именно поэтому TCO включает labor: труд сотрудников является экономическим ресурсом, даже когда разработчику за него не приходит отдельный счёт. FinOps также относит labor и productivity losses к составляющим полной стоимости владения IT.

Простой сайта: сервер может стоить 3 000 ₽, а час сбоя — 50 000 ₽

Рассмотрим интернет-магазин.

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

300 000 ₽ в сутки.

Для упрощённой модели разделим равномерно:

300 000 / 24 = 12 500 ₽ в час

Четыре часа полного outage:

12 500 × 4 = 50 000 ₽

Это не значит, что любой четырёхчасовой сбой гарантированно уничтожает ровно 50 тысяч рублей.

Продажи распределены по суткам неравномерно.

Часть клиентов вернётся позже.

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

Но расчёт показывает порядок величины.

И внезапно инфраструктурный спор:

платить 1 000 или 3 000 ₽ в месяц за сервер?

нужно рассматривать не только относительно цены самого сервера, но и относительно стоимости отказа.

Именно поэтому TCO в IT включает opportunity cost of downtime.

Четыре проекта — четыре совершенно разные экономики

Чтобы не обсуждать абстрактный «сайт», сравним четыре модели.

Важно: цифры ниже — не среднерыночный прайс России и не предложение Vagizov.com. Это модельные сценарии, созданные специально для понимания структуры расходов.

1. Лендинг малого бизнеса

Например, электрик.

Сайт небольшой.

Контент меняется редко.

Нет сложной интеграции.

Shared hosting достаточен.

Несколько изменений в год.

За три года модель может выглядеть так:

• разработка — 80 000 ₽;
• инфраструктура — 18 000 ₽;
• обслуживание — 45 000 ₽;
• изменения — 45 000 ₽;
• внутреннее время бизнеса — 18 000 ₽;
• резерв на непредвиденные работы — 20 000 ₽.

Модельный TCO: 226 000 ₽.

2. Корпоративный WordPress

Несколько направлений бизнеса.

Формы.

CRM.

Статьи.

Регулярные изменения.

Платные компоненты.

За три года модель:

• разработка — 350 000 ₽;
• инфраструктура — 45 000 ₽;
• лицензии — 75 000 ₽;
• техническое обслуживание — 210 000 ₽;
• развитие — 270 000 ₽;
• внутренний труд — 90 000 ₽;
• миграции и непредвиденные работы — 100 000 ₽.

Модельный TCO: 1 140 000 ₽.

3. Интернет-магазин

Здесь уже есть каталог, оплата, доставка, feeds, склад, CRM или 1С, регулярные изменения.

Модель:

• разработка — 800 000 ₽;
• инфраструктура — 180 000 ₽;
• лицензии — 150 000 ₽;
• maintenance — 480 000 ₽;
• развитие и интеграции — 720 000 ₽;
• внутренний труд — 270 000 ₽;
• инциденты и миграции — 300 000 ₽.

Модельный TCO: 2 900 000 ₽.

4. Индивидуальная система

Здесь цена домена уже практически теряется в округлении.

Основные расходы:

• команда;
• releases;
• QA;
• DevOps;
• database;
• monitoring;
• security;
• product changes.

Допустим:

• разработка первой версии — 3 000 000 ₽;
• инфраструктура за три года — 720 000 ₽;
• licenses/services — 180 000 ₽;
• support/engineering — 3 600 000 ₽;
• развитие — 3 600 000 ₽;
• internal operations — 900 000 ₽;
• migration/incidents — 900 000 ₽.

Получаем:

12 900 000 ₽ за три года.

Не потому, что домен дорогой.

А потому, что перед нами уже полноценная программная система.

Сводная таблица

Проект	Стартовая разработка	Эксплуатация, развитие и резерв за 3 года	Модельный TCO
лендинг малого бизнеса	80 000 ₽	146 000 ₽	226 000 ₽
корпоративный WordPress	350 000 ₽	790 000 ₽	1 140 000 ₽
интернет-магазин	800 000 ₽	2 100 000 ₽	2 900 000 ₽
индивидуальный сервис	3 000 000 ₽	9 900 000 ₽	12 900 000 ₽

Ещё раз: это модель, а не рыночный справочник цен.

Её задача показать другое:

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

Дорогой сайт тоже может быть дорогим в эксплуатации

После таблицы легко прийти к удобному маркетинговому выводу:

платите больше на старте — и потом всё будет дёшево.

Это неправда.

Компания может потратить 900 000 ₽ на разработку и получить:

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

Такой сайт будет дорогим и на старте, и после запуска.

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

Снижает будущую стоимость не чек, а поддерживаемость решения.

Что такое поддерживаемая архитектура с финансовой точки зрения

Хорошая архитектура — это не обязательно Kubernetes, микросервисы и документация на 400 страниц.

Для небольшого WordPress это может означать совершенно приземлённые вещи:

• данные хранятся структурированно;
• theme не ломается от изменения одного блока;
• используется минимум действительно нужных plugins;
• код находится в Git;
• существует staging;
• backup можно восстановить;
• обновления проходят предсказуемо;
• разработчику не нужно каждый раз заново изучать загадочные костыли.

В таком проекте новая задача:

добавить ещё один тип услуги

может занимать несколько часов.

В другом визуально идентичном сайте:

добавьте такую же услугу

требует переписать шаблон и проверить двадцать связанных мест.

На первой неделе эти сайты выглядят одинаково.

Разница становится видна на двадцатой доработке.

Технический долг — это финансовый долг без фиксированной процентной ставки

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

Разработчик сегодня выбирает быстрое решение.

Оно дешевле сейчас.

Но увеличивает сложность системы.

Через год новая функция требует больше времени.

Потом ещё больше.

Получается цепочка:

экономия сегодня → дополнительная сложность → более дорогие изменения завтра

Но важно не впасть в другую крайность.

Не любой технический долг плох.

Иногда бизнесу действительно выгоднее быстро проверить гипотезу за 30 000 ₽, чем проектировать идеальную систему за 500 000 ₽ для продукта, который может вообще никому не понадобиться.

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

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

SEO входит в TCO или нет

Здесь я бы не использовал удобную для SEO-специалиста формулу:

без SEO сайт не существует.

Существует.

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

Поэтому SEO не является обязательной строкой технического TCO.

Но если бизнес инвестировал в сайт именно как в канал получения клиентов из поиска, SEO становится частью общей экономики этого канала.

Например:

Core TCO

• разработка;
• hosting;
• licenses;
• support;
• security;
• backups.

Growth

• новые landing pages;
• development;
• content;
• CRO;
• integrations.

Acquisition

• SEO;
• контекст;
• платные площадки;
• другие каналы.

Такое деление позволяет сравнивать вещи честно.

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

Хотя техническая стоимость их инфраструктуры может быть почти одинаковой.

Не все доработки являются расходом — часть из них инвестиция

Представим, компания платит:

100 000 ₽

за интеграцию сайта с CRM.

Если считать только TCO, сумма выросла.

Но интеграция экономит:

• 30 часов сотрудников ежемесячно;
• уменьшает число потерянных лидов;
• ускоряет обработку заявок.

Значит, оценивать её только как расход бессмысленно.

Именно здесь TCO переходит в unit economics и ROI.

Низкий TCO сам по себе не должен быть целью.

Можно сделать сайт практически бесплатным:

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

И получить очень дешёвую систему, которая почти не приносит бизнесу ценности.

Поэтому оптимальный вопрос:

какая стоимость владения оправдана результатом, который система даёт компании?

Миграции — нормальная часть жизненного цикла

За три года сайт может пережить:

• перенос hosting;
• переход на VPS;
• новую PHP;
• смену CDN;
• другой SMTP;
• обновление API;
• изменение DNS;
• нового подрядчика;
• реструктуризацию проекта.

Это не обязательно означает ошибку первоначального исполнителя.

Технологическая среда и сам бизнес меняются.

Но архитектура влияет на стоимость таких изменений.

Сайт с понятным Git, документацией, backup и стандартным стеком переносится одним способом.

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

И вот здесь связь TCO с вопросом владения становится прямой:

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

Таблица: какие расходы относить к какому уровню

Расход	Core TCO	Развитие	Маркетинг
домен	✓
hosting/VPS	✓
backup	✓
лицензии CMS/plugins	✓
технические обновления	✓
устранение аварии	✓
новый калькулятор		✓
интеграция CRM		✓
новый раздел бизнеса		✓
SEO			✓
контент для органического поиска			✓
контекстная реклама			✓

Граница не всегда абсолютно строгая.

Например, изменение контента может быть обычной эксплуатацией или SEO-задачей.

Но даже приблизительное разделение гораздо честнее, чем одно число «содержание сайта».

Как посчитать TCO сайта на три года

Шаг 1. Зафиксируйте стоимость запуска

Включите не только программирование.

Учтите:

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

Шаг 2. Выпишите все повторяющиеся платежи

Для каждого укажите:

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

Например:

Компонент	Период
домен	ежегодно
hosting	ежемесячно/ежегодно
ACF PRO	ежегодно
SMTP	ежемесячно
monitoring	ежемесячно

Шаг 3. Посчитайте техническое обслуживание

Не только плановый retainer.

Включите реальную ожидаемую работу:

• обновления;
• проверки;
• backup;
• мониторинг;
• исправления.

Шаг 4. Добавьте прогнозируемые изменения бизнеса

Какие задачи почти наверняка возникнут за три года?

Например:

• новые услуги;
• интеграции;
• переработка каталога;
• новый город;
• личный кабинет.

Не нужно угадывать всё.

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

Шаг 5. Посчитайте внутренний труд

Если сотрудник регулярно выполняет ручную работу из-за ограничений сайта, посчитайте:

часы в месяц × 36 × стоимость часа

Этот расход реален, даже если не приходит отдельным счётом.

Шаг 6. Оцените последствия простоя

Для коммерчески критичных систем:

маржинальный результат за период × длительность недоступности

Используйте сценарии, а не попытку предсказать точное число аварий.

Шаг 7. Добавьте reserve на migration/incidents

Особенно для систем, которые активно развиваются.

Не обязательно заранее знать конкретную аварию.

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

Шаг 8. Отделите маркетинг

Не смешивайте базовый TCO с:

• SEO;
• рекламой;
• производством маркетингового контента.

Сначала посчитайте саму платформу.

Потом — экономику привлечения клиентов.

Шаг 9. Получите трёхлетнюю модель

Упрощённо:

TCO₃ = Initial + Recurring₃ + Maintenance₃ + Required Changes + Internal Labor + Incidents

Отдельно:

Business Website Cost = TCO₃ + Growth + Acquisition

Теперь цену двух вариантов сайта можно сравнивать намного честнее.

Что просить у подрядчика ещё до начала разработки

Если проект должен жить несколько лет, полезно спрашивать не только:

сколько стоит разработка?

Добавьте:

Какие обязательные ежегодные расходы появятся после запуска?

Какие plugins платные?

Где будет hosting?

Как делаются backup?

Кто обновляет CMS?

Сколько обычно стоит типовая доработка?

Можно ли передать проект другому специалисту?

Какие сторонние сервисы оплачиваются отдельно?

Что произойдёт, если мы три года не будем менять функциональность?

Как изменится стоимость, если ассортимент вырастет в десять раз?

Подрядчик не сможет назвать точный TCO до 2029 года.

И это нормально.

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

Если ответ:

после запуска вообще никаких расходов не будет,

это уже повод спросить подробнее.

Переделывать или продолжать поддерживать

В какой-то момент у старого сайта возникает ещё один экономический вопрос:

продолжать вкладываться или переделать?

Его тоже нельзя решать только по прошлым затратам.

Если сайт пять лет стоил дорого, это не причина потратить ещё столько же.

Прошлые расходы — sunk cost.

Нужно сравнивать будущие сценарии:

Продолжаем текущий

Сколько стоят:

• maintenance;
• типовая доработка;
• исправление технического долга;
• будущие миграции.

Переделываем

Сколько стоят:

• новый проект;
• migration;
• SEO-риски;
• перенос данных;
• обучение команды;
• параллельная эксплуатация.

И уже эти будущие денежные потоки сравниваются между собой.

Почему цена создания всё равно важна

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

Имеет.

Для маленького проекта она может оставаться крупнейшей статьёй расходов.

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

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

Если сайт почти не будет меняться

Простота может быть преимуществом.

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

Поддерживаемость становится экономическим фактором.

Если это e-commerce

Нужно заранее учитывать интеграции, uptime и эксплуатацию.

Если это собственный сервис

Стоимость разработки первой версии может быть только небольшой частью будущего engineering budget.

То есть TCO не учит:

всегда покупайте дороже.

Он учит:

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

Когда постоянная техническая поддержка не нужна

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

Если у бизнеса:

• небольшой сайт;
• редкие изменения;
• простой stack;
• хороший managed hosting;
• нет критичных integrations;
• нет e-commerce;

может хватать периодических проверок и разовых работ.

Постоянная поддержка оправдана, когда цена отказа и частота изменений достаточно высоки.

Именно поэтому услуга «Развитие и техническое сопровождение сайта» на Vagizov.com рассматривается как отдельный формат для проектов с backlog, интеграциями и техническим долгом, а не как обязательный налог на каждый WordPress.

Цена разработки на Vagizov.com тоже не является TCO

Например, текущая услуга разработки сайтов Vagizov.com начинается от 180 000 ₽ и разделяет форматы от WordPress Старт до более сложных систем. Эта сумма описывает проект разработки, а не обещание, что следующие три года сайт ничего не будет стоить.

Так же отдельно существует развитие сайта как регулярная работа.

Мне кажется важным не скрывать это разделение.

Если бизнес покупает сайт за 300 000 ₽, он должен понимать:

300 000 ₽ — цена получения определённой версии системы.

Не пожизненная подписка на любые будущие изменения компании.

Если нужен новый сайт, структура проекта и дальнейшая поддерживаемость закладываются в услуге «Разработка сайтов».

Главное

Цена автомобиля в салоне и стоимость владения автомобилем за три года никогда не были одним и тем же числом.

С сайтом происходит ровно то же самое.

Стоимость разработки отвечает на вопрос:

сколько стоило получить эту систему в день запуска?

TCO отвечает на другой:

сколько стоило реально владеть, обслуживать и использовать её в течение трёх лет?

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

При этом не нужно искусственно раздувать сумму.

Бесплатный Let’s Encrypt остаётся бесплатным.

Небольшому сайту действительно может хватить недорогого shared hosting.

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

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

Поэтому правильный вывод не такой:

дешёвый сайт плохой, дорогой хороший.

Правильный вывод:

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

Иногда сайт за 15 000 ₽ действительно оказывается отличной покупкой.

Иногда через три года он стоит бизнесу 257 000 ₽.

Сайт за 500 000 ₽ может через те же три года обойтись в миллион.

А серьёзный интернет-магазин или собственный сервис вообще живёт в другой экономической реальности, где цена домена уже почти не видна на фоне команды, infrastructure и разработки.

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

Я бы спрашивал:

Сколько эта система будет стоить нам, когда мы действительно начнём ей пользоваться?

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