Стоимость сайта после запуска: почему цена разработки — только часть TCO

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

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

Поэтому реальная стоимость цифрового продукта определяется не только ценой разработки. Для этого существует понятие TCO — Total Cost of Ownership , или совокупная стоимость владения. Главный вопрос для бизнеса должен звучать не только так: «Сколько стоит создать сайт?» Но и так: «Сколько будет стоить владеть этим продуктом следующие три-пять лет?» Что входит в TCO сайта Упрощённо совокупную стоимость владения можно представить так: TCO = разработка + инфраструктура + поддержка + изменения + лицензии + исправления + стоимость технического долга

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

1. Первоначальная разработка

Это самая заметная статья бюджета. В неё входят:

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

Именно эту цифру чаще всего сравнивают при выборе подрядчика. Но низкая стартовая стоимость ещё не означает низкую стоимость владения. Иногда происходит наоборот. Часть расходов просто переносится в будущее. 2. Hosting и инфраструктура После запуска сайт нужно где-то размещать. Расходы могут включать:

• сервер;
• managed hosting;
• базу данных;
• CDN;
• storage;
• резервные копии;
• мониторинг;
• почтовые сервисы;
• SSL;
• staging;
• production infrastructure.

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

• выдержит ли он нагрузку;
• можно ли его масштабировать;
• настроены ли backup;
• что произойдёт при сбое;
• как быстро можно восстановить систему.

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

• браузеры;
• устройства;
• API;
• требования безопасности;
• зависимости;
• бизнес-процессы.

Поэтому системе нужна поддержка. В зависимости от проекта она может включать:

• обновление компонентов;
• мониторинг;
• исправление ошибок;
• помощь редакторам;
• контроль интеграций;
• резервное копирование;
• security updates.

Если архитектура сделана аккуратно, поддержка занимает относительно мало времени. Если продукт собран хаотично, даже небольшая задача может превращаться в исследование. Именно здесь первоначальная экономия часто начинает исчезать. 4. Стоимость изменений Бизнес редко остаётся таким же, каким был в день запуска сайта. Появляются:

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

Поэтому один из важнейших вопросов: Насколько дорого менять систему? Представим два сайта. В первом маркетолог может самостоятельно:

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

Во втором каждая операция требует разработчика. Внешне сайты могут выглядеть одинаково. Но стоимость владения будет совершенно разной. 5. Лицензии Некоторые сайты зависят от платных компонентов. Например:

• CMS;
• плагины;
• конструкторы;
• аналитика;
• CRM;
• шрифты;
• формы;
• email-сервисы;
• search;
• CDN;
• security tools.

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

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

6. Ручная работа Одна из самых недооценённых частей TCO. Допустим, сайт не умеет автоматически передавать заявки в CRM. Менеджер каждый день копирует их вручную. Это тоже стоимость владения. Только она находится не в бюджете IT, а в зарплате сотрудников. Другие примеры:

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

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

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

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

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

Сайт A

Стоимость разработки: 200 000 ₽

Сайт B

Стоимость разработки: 500 000 ₽ На первый взгляд сайт A выгоднее. Разница — 300 000 ₽. Если смотреть только на бюджет запуска, решение кажется очевидным. Но посмотрим на следующие три года. Сайт A после запуска Первоначально продукт стоил дешевле. Но затем выясняется:

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

За три года бизнес постоянно оплачивает: разработчиков Даже ради небольших изменений. исправления Потому что изменения периодически ломают существующий функционал. лицензии Для плагинов и сервисов, на которых построен продукт. ручную работу Потому что часть процессов не автоматизирована. дорогие изменения Потому что архитектура плохо адаптирована к развитию. Первоначальные 200 000 ₽ больше не выглядят полной стоимостью продукта. Сайт B после запуска На старте он стоил дороже. Но при разработке были предусмотрены:

• CMS;
• automation;
• tests;
• documentation;
• управляемая архитектура;
• понятный процесс deployment.

Теперь команда может самостоятельно менять большую часть контента. Автоматические тесты проверяют критические сценарии. Deployment выполняется предсказуемо. Новый разработчик может открыть документацию и разобраться в системе. Интеграции подключаются через понятный API. В результате стоимость регулярных изменений ниже. Какой сайт дешевле? В первый день: A = 200 000 ₽ B = 500 000 ₽ По стартовой цене A дешевле более чем в два раза. Но через несколько лет ситуация может выглядеть иначе. Условный пример: Расход за 3 годаСайт AСайт BРазработка200 000 ₽500 000 ₽Поддержка450 000 ₽180 000 ₽Доработки600 000 ₽250 000 ₽Исправления250 000 ₽80 000 ₽Лицензии180 000 ₽60 000 ₽Ручная работа300 000 ₽80 000 ₽ Итого1 980 000 ₽1 150 000 ₽

Цифры здесь иллюстративные. Но принцип важен. Проект с более высокой ценой запуска способен оказаться дешевле по совокупной стоимости владения. Админка — это не просто удобство CMS иногда воспринимают как дополнительную функцию сайта. На самом деле хорошая админка напрямую влияет на TCO. Если сотрудник может сам:

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

бизнес не оплачивает разработчика ради этих операций. Представим: одна небольшая правка через разработчика стоит бизнесу 2 000 ₽. Таких изменений — 15 в месяц. Получаем: 30 000 ₽ в месяц или 360 000 ₽ в год. За три года — больше миллиона рублей только на простые контентные операции. Хорошая CMS может убрать значительную часть этого расхода. Автоматизация снижает стоимость владения То же самое относится к техническим процессам. Если deployment выполняется вручную, разработчик:

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

Если настроен CI/CD, большая часть процесса происходит автоматически. Аналогично с тестированием. Без тестов после каждого изменения приходится вручную проверять систему. С тестами критические сценарии проверяются автоматически. Автоматизация стоит денег при внедрении. Но затем работает при каждом следующем релизе. Документация тоже имеет экономическую ценность Документацию часто откладывают: «Разработчики и так всё знают». Проблема появляется через год. Разработчик меняется. Новая команда начинает изучать проект. Неделю. Две. Месяц.

Всё это оплачивает бизнес. Документация сокращает стоимость передачи системы между людьми. Она должна отвечать хотя бы на основные вопросы:

• как устроен продукт;
• как его запускать;
• как выполнять deployment;
• где находятся интеграции;
• как делать backup;
• какие зависимости используются;
• как восстановить систему.

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

Техническое решение должно соответствовать сроку жизни продукта. Что спросить у подрядчика до начала разработки Вместо одного вопроса: «Сколько стоит сайт?» полезно задать ещё несколько. Кто сможет менять контент после запуска? Какие изменения можно делать без разработчика? Какие регулярные лицензии потребуются? Как будет выполняться deployment? Есть ли staging? Будут ли автоматические тесты? Как делаются backup? Будет ли документация? Как подключаются новые интеграции? Что произойдёт, если через год проект возьмёт другой разработчик?

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

• CMS уменьшает зависимость от разработчика;
• тесты уменьшают количество ошибок;
• CI/CD уменьшает стоимость релиза;
• документация упрощает поддержку;
• API облегчает интеграции;
• модульная архитектура делает изменения дешевле;
• мониторинг позволяет быстрее находить сбои.

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

Она должна оставаться экономически разумной в течение всего срока жизни продукта. Главный вывод Сравнивая предложения на разработку сайта, не стоит смотреть только на первую цифру. Сайт за 200 000 ₽ может оказаться дороже сайта за 500 000 ₽, если следующие три года он постоянно требует разработчиков, ручной работы, исправлений и дорогих изменений. Поэтому правильный вопрос звучит так: Не только «сколько стоит создать?», но и «сколько будет стоить владеть этим продуктом?»

Хотите понять реальную стоимость вашего сайта?

VERB может провести аудит текущего продукта и определить, из чего складывается его TCO:

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

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