Сколько стоит кастомный сайт в 2026 году?

На удивительно сложный вопрос есть удивительно простой ответ.

Реально кастомный сайт в США может стоить от $15,000 до $150,000+.

Этот диапазон сам по себе почти бесполезен.

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

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

Реальный вопрос не в том, сколько стоит сайт. Он в том: что бизнесу реально нужно от этого сайта?

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

WHAT DRIVES PRICE

Что реально двигает цену?

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

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

Интеграции. Должен ли сайт общаться с чем-то ещё? CRM. ERP. Система инвентаря. Платёжный провайдер. Платформа бронирования. Маркетинговая автоматизация. Внутренняя база данных. Служба доставки. Бухгалтерский софт.

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

Интерфейс всё ещё может выглядеть простым. Система под ним нет.

DATA ARCHITECTURE

Архитектура данных и контента

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

Есть ли у товаров варианты? Конфигурации? Несколько цен? Региональная доступность? Разные спецификации? Связанные товары? Кастомные атрибуты? Несколько языков?

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

Модель данных под сайтом может стать важнее, чем страницы, что реально видит клиент.

BUSINESS LOGIC

Кастомная бизнес-логика и владение после запуска

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

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

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

Вопрос поэтому не только «сколько стоит построить?» Это ещё и: сколько будет стоить понять и изменить это через два года? Этот вопрос часто отсутствует в изначальной оценке.

WHY QUOTES DIFFER

Почему два агентства могут оценить одно и то же в $40,000 и $100,000

Это одна из самых странных вещей, с чем сталкиваются клиенты. Два агентства получают один документ. Одно оценивает в $40,000. Другое в $100,000. Оба выглядят компетентными. Ни одно не обязательно нечестное.

Они просто могут оценивать разные проекты, скрытые внутри одного и того же брифа.

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

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

Оба оценивают один документ. Только одно оценивает один проект. Эта разница может стоить десятков тысяч долларов.

DISCOVERY

Предложение хорошо ровно настолько, насколько хорош discovery за ним

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

Клиент описывает, что хочет. Агентство выдаёт цифру. Проект начинается. Потом все обнаруживают, чего не было в изначальном описании. Именно там оценки начинают двигаться.

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

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

Хороший discovery поэтому не бюрократия перед разработкой. Это часть разработки.

PRICING MODELS

Фиксированная цена, почасовая или ретейнер

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

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

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

Ни одна из этих моделей не лучше по своей природе. Они просто по-разному распределяют риск и неопределённость.

AI AND COST

Делает ли AI кастомные сайты дешевле?

AI изменил, как строятся сайты. Он не изменил, как работает бизнес. Это различие важно сейчас как никогда, то же, что мы разбираем в Стоимость AI, это не генерация. Это верификация.

Сегодня владелец бизнеса может открыть ChatGPT, Claude или другой AI-инструмент и описать сайт, что хочет. Через минуты у него могут быть карта сайта, список фич, технические рекомендации, вайрфреймы, предложения по базе данных и даже рабочий код. С современными AI-ассистированными инструментами разработки удивительно способный прототип можно сгенерировать за часы.

Для простых проектов это реально трансформационно. Лендинг. Сайт малого бизнеса. Простой каталог. Простой внутренний инструмент. AI может убрать огромные объёмы ненужного производственного времени из этих проектов.

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

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

Владелец бизнеса может сказать «нам нужен конфигуратор продукта». Звучит как техзадание. Это не так. Что конфигуратор реально рассчитывает? Какие опции влияют на цену? Могут ли определённые комбинации быть недоступны? Разные ли цены для разных клиентов? Нужно ли конфигурации генерировать предложение, что попадает в CRM? Может ли продавец его изменить? Что происходит, когда тот же товар существует на другом рынке с другой валютой?

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

PROTOTYPE VS SYSTEM

В чём AI реально хорош, и где он прячет проблему

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

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

Это, возможно, самая опасная часть: AI может создать что-то, что выглядит законченным задолго до того, как реально закончено. У тебя могут быть красивые экраны, рабочий логин, каталог товаров, checkout, дашборд, API, база данных. Всё выглядит так, будто оно есть.

Прототип демонстрирует, что что-то можно построить. Он не демонстрирует, что это правильная система для бизнеса.

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

Есть ещё один вопрос, что бизнесы редко задают, когда AI-сгенерированный сайт работает идеально в первый день: что реально под ним? Страница может выглядеть одинаково для пользователя вне зависимости от того, построена ли она на Laravel, WordPress, Next.js, наборе сторонних сервисов, сгенерированных компонентах, кастомных API, или смеси всего этого. Браузеру всё равно. Бизнесу в итоге нет.

AI TECHNICAL DEBT

Как технический долг начинается с AI-сгенерированного кода

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

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

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

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

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

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

DISCOVERY IN AI ERA

AI не устраняет discovery. Он делает его важнее.

Когда разработка была медленной и дорогой, стоимость создания чего-либо заставляла команды тщательно думать перед стартом. Теперь стоимость производства первой версии может быть крайне низкой. Это прекрасно. Но это также делает опасно лёгким построить не то.

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

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

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

AI это ускоритель. Не замена пониманию того, куда ты движешься.

COST COMPOSITION

Что это значит для стоимости кастомной разработки

Именно поэтому мы не ожидаем, что AI просто урежет стоимость серьёзной кастомной разработки вдвое. Он меняет состав стоимости, тот же сдвиг, что мы разбираем в Как AI меняет разработку продукта в 2026.

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

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

COMPARING PROPOSALS

Почему финальная цена часто выше первого предложения

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

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

Иногда самое дешёвое на вид предложение это просто предложение с наибольшим числом неотвеченных вопросов.

Сравнивая предложения, не смотри только на итог. Смотри, что реально включено: discovery, информационная архитектура, UX-исследование, техническая архитектура, интеграции, кастомная бизнес-логика, миграция контента, QA, документация, деплой, обучение, поддержка после запуска, поддержка, управление изменениями.

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

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

Так сколько же должен стоить твой кастомный сайт? Осмысленного ответа нет, пока мы не понимаем, что сайту реально нужно делать. Сайт за $20,000 может быть дорогим, если его нужно пересобрать через год. Платформа за $100,000 может быть недорогой, если она заменяет ручные процессы, интегрируется с бизнесом, масштабируется с ростом и остаётся поддерживаемой годами. Сама цифра говорит очень мало. Важно, отражает ли цифра реальную сложность бизнеса. И именно для этого нужен discovery.