Корпоративный сайт — как ремонт: сначала кажется, что надо только переклеить обои, а через месяц уже меняешь проводку и несущие стены. С сайтами происходит примерно то же самое: каждая «небольшая доработка» открывает следующую комнату. Вот здесь и начинается взрослая веб-разработка для бизнеса.
В понедельник маркетинг просит добавить каталог. Через месяц продажи хотят персональные цены. Потом партнёрам нужен личный кабинет, бухгалтерии — документы из 1С, складу — передавать остатки, а CRM — получать заявки. В пятницу вечером выясняется, что один старый PHP-скрипт, написанный человеком, которого никто не видел четыре года, участвует вообще во всём.
В интерфейсе по-прежнему есть логотип, меню и кнопка «Оформить заказ», поэтому внутри компании проект продолжают называть сайтом. Технически перед вами уже веб-приложение, B2B-портал или корпоративная система, через которую проходят деньги, данные и бизнес-процессы. Если такая система падает, IT-отдел моментально окупает годы своей незаметной работы.
Семь признаков, что ваш сайт уже стал системой
Как узнать что сайт стал системой? Фраза «давайте просто добавим» звучит как вежливое начало технического звездеца. Просто разные цены для дилеров. Просто остатки из 1С. Просто документы в личном кабинете. Просто синхронизация заказов с CRM.
Уровень сложности системы можно оценить по нескольким признакам:
1. Сайт получает данные сразу из нескольких систем: цены живут в ERP, товары — в PIM, клиенты — в CRM, остатки — в 1С или WMS.
2. У пользователей появляются роли: дилер видит одно, клиент другое, бухгалтер третье.
3. Внутри возникают расчёты, согласования, лимиты, персональные условия и генерация документов.
4. Если система лежит два часа, вместе с ней останавливаются заказы, обслуживание клиентов или работа партнёров.
5. Каждая новая функция требует всё более сложных доработок. Разработчик начинает предложение словами «вообще CMS так делать не умеет, но…», а после «но» обычно начинается бюджет.
6. Данные приходится параллельно исправлять в нескольких местах: менеджер меняет характеристику товара в 1С, маркетолог — на сайте, контент-менеджер — в каталоге, и через месяц у одного товара появляются три версии правды.
7. Финальная стадия — команда начинает бояться обновлений. Фраза «Bitrix пока лучше не обновлять» звучит всё чаще.
Один-два таких симптома система выдержит. Если узнаёте четыре или пять, архитектуру пора разбирать целиком.
От сайта к веб-приложению: как растёт сложность
Возьмем производителей оборудования. Сначала им нужно разработать корпоративный сайт: рассказать о компании, показать продукцию, собрать заявки. Готовая CMS прекрасно справляется. Через пару лет каталог разрастается до нескольких тысяч товаров, появляются сотни характеристик, сертификаты, инструкции, фотографии и несколько каналов продаж. Те же данные нужны дилерам, маркетплейсам и печатным каталогам.
В этот момент появляется PIM или другой единый источник продуктовой информации. Затем продажи просят личный кабинет. У каждого дилера собственные цены и ассортимент, цены приходят из ERP, остатки — из 1С, документы формируются в учётной системе. Появляется API. Следом выясняется, что менеджер клиента создаёт заказ, руководитель его согласовывает, а бухгалтеру нужен доступ только к документам. Появляются авторизация и ролевая модель.
Через некоторое время бизнес хочет историю операций, уведомления, статусы доставки, повторные заказы и аналитику. Корпоративный сайт к этому моменту успешно эволюционировал в B2B-портал. Frontend всё ещё показывает аккуратные карточки товаров, а backend уже занимается бизнес-логикой, базой данных, очередями, интеграциями и правами. Где-то рядом живут CRM, ERP, 1С, PIM и внешние сервисы.
А архитектура всей этой конструкции по-прежнему соответствует первой версии сайта, и когда лёд треснет, под ним будет ждать счёт за годы технического долга.
Реальный пример: 18 000 товаров и контент, который ехал до трёх недель
Maytoni работает с интерьерным освещением примерно в 35 странах, каталог компании насчитывает около 18 тысяч SKU. Продуктовые данные были распределены между 1С ERP, медиахранилищем и Bitrix24. Срочные изменения могли занимать 3–4 дня, обычные — от одной до трёх недель.
Сайт в этой ситуации оказался только одним из мест, где проявлялась проблема. Данные о товарах жили сразу в нескольких системах, а любое изменение должно было пройти через всю эту цепочку, прежде чем попасть к клиенту. Поэтому мы внедрили PIMcore: 1С осталась источником артикулов, цен, остатков и характеристик, PIMcore взял на себя обогащение данных, медиаматериалы и публикацию, а Bitrix24 сохранили в привычном процессе постановки задач. Для медиаданных подключили S3 через API, автоматизировали привязку файлов к SKU и построили очереди обмена. После этого единый поток данных начал расходиться в публичный каталог, российский и немецкий сайты и на маркетплейсы.
История Maytoni хорошо показывает момент, когда задача веб-разработки выходит за пределы самого сайта. Если данные неделями добираются до витрины из-за того, как устроены внутренние системы, ускорять одну витрину бессмысленно. Сначала приходится разбираться, где рождаются данные, как они меняются и каким путём доходят до пользователя.
CMS, гибрид или заказная веб-разработка
Когда сайт начинает превращаться в систему, бизнес обычно оказывается перед тремя вариантами: продолжать развивать CMS, разделить систему на готовые и собственные компоненты или переходить к заказной разработке. Выбор зависит от количества собственной бизнес-логики.
CMS прекрасно работает там, где ядро проекта — контент. Корпоративные сайты, блоги, небольшие каталоги и посадочные страницы получают от готовой платформы огромную пользу: административный интерфейс уже существует, редакторы могут работать самостоятельно, типовые функции реализованы.
Переломный момент наступает, когда большая часть нового функционала появляется благодаря слову «доработаем». CMS обрастает модулями, модули начинают зависеть друг от друга, обновления превращаются в приключение, а документация перестаёт описывать реальную систему. Компания часто продолжает вкладываться, потому что «мы уже столько денег сюда вложили». Это описание безвозвратных издержек, а не аргумент в пользу архитектуры.
Для многих корпоративных проектов разумнее гибрид. CMS продолжает заниматься страницами и контентом, а рядом появляются отдельные веб-сервисы для личного кабинета, поиска, расчётов или интеграций. Каталог получает данные из PIM, цены приезжают из ERP или 1С, заказы уходят через API, авторизация работает отдельно. Сложность такого подхода находится в границах: если вынести каждый чих в микросервис, компания получит Kubernetes раньше, чем получит пользователей. Если оставить всю бизнес-логику внутри CMS, через пару лет разговор начнётся заново.
Полностью заказная веб-разработка оправдана там, где специфика бизнеса и есть сама система: B2B-платформа, маркетплейс, SaaS, сложный личный кабинет, внутренняя автоматизация или высоконагруженный сервис. Здесь уже приходится самостоятельно проектировать модель данных, backend, API, роли, очереди, интеграции, отказоустойчивость и безопасность. Свободы становится больше, и цена архитектурной ошибки растёт вместе с ней.
Реальный пример: Excel, который оказался ценнее красивой архитектуры
Для компании «Алгоритм» мы разрабатывали сайт с каталогом ASIC-майнеров и расчётом потенциальной доходности оборудования. Самая сложная часть проекта находилась вовсе не в каталоге. У заказчика уже существовала финансовая модель в Excel: несколько больших листов, множество параметров, прогнозы курса биткоина, стоимость оборудования, сложность сети, халвинг и другие факторы.
Очевидное инженерное решение — переписать всю математику в код. Звучит солидно, архитекторы довольны, Excel побеждён. Только сама модель продолжала меняться. После полного переноса каждое изменение методики превращалось бы в новую задачу разработчику, поэтому финансовую модель сохранили управляемой и встроили в веб-систему.
Расчёт, который первоначально занимал около 30 секунд, в итоге ускорили примерно до 4 секунд. Вокруг него появилась полноценная система: публичный каталог, административная часть, кабинеты сотрудников и китайских поставщиков, роли, история цен и продаж. Если цена поставщика менялась больше чем на 5%, система предупреждала об этом и отправляла уведомление в Telegram.
На проект ушло около 4000 часов. Эта цифра полезнее большинства абстрактных прайсов. При проекте такого масштаба каждые дополнительные 500 ₽ в средней стоимости часа превращаются в 2 млн ₽ бюджета. Если из-за неверного архитектурного решения приходится переделать хотя бы 20% системы, это ещё 800 часов. Даже при условной стоимости 3000 ₽ за час речь идёт о 2,4 млн ₽.
Разговор об архитектуре — это разговор о деньгах в диаграммах.
Сложность веб-разработки не видна на экране
Маленькая кнопка «Оформить заказ» скрывает половину ИТ-ландшафта компании. После её нажатия система должна проверить пользователя и его права, получить персональную цену, проверить остатки, применить договорные условия, создать заказ, отправить данные в ERP, зарезервировать товар, передать информацию в CRM, инициировать оплату и вернуть пользователю корректный статус.
А если ERP временно недоступна? Создавать заказ или ждать? Что показать клиенту? Нужно ли повторять операцию? Что произойдёт, если ERP оживёт через минуту и получит запрос второй раз? Как понять, был ли первый запрос обработан?
Вот где живёт значительная часть стоимости веб-разработки. То же самое относится к данным и ролям. Если карточка товара собирается из ERP, PIM и внутренних справочников, нужно определить источник истины для каждого поля. Если системой пользуются несколько организаций, подразделений и должностей, модели «администратор / пользователь» быстро перестаёт хватать. Чем больше через веб-приложение проходит коммерческих и персональных данных, тем важнее становятся авторизация, аудит действий, защита API и контроль доступа.
Сколько стоит веб-разработка для бизнеса
Есть средняя по рынку универсальная величина: корпоративный сайт — 800 тысяч руб., веб-приложение — 2 млн, портал — 5 млн. А потом открывается реальная архитектура, и весь этот прайс превращается в декоративную х%#ню.
Стоимость сильнее всего определяют четыре вещи: бизнес-логика, интеграции, данные и неопределенность. Показать карточку товара относительно дёшево. Рассчитать персональные условия для конкретного клиента уже сложнее. Каждая учётная, платёжная система или внешний API добавляет зависимости и сценарии отказа. Чистая новая база сильно отличается от двадцати лет исторических данных в трёх системах и одном Excel Сергея Петровича. А фраза «точно поймём по ходу разработки» имеет вполне конкретную стоимость.
Для проектов класса, которыми занимается серьёзная компания со зрелой командой, бюджет обычно начинается примерно от 3–4 млн ₽. Если требуется несколько интеграций, сложные роли, собственная бизнес-логика и заметный объём backend-разработки, сумма быстро растёт дальше. При бюджете до миллиона рублей рациональнее использовать готовые решения и сокращать индивидуальную разработку.
При этом смотреть только на стоимость запуска опасно. Система за 4 млн ₽, которую можно спокойно развивать пять лет, способна оказаться дешевле системы за 1,5 млн ₽, с которой каждый новый релиз начинается с вопроса: «а эта хрень вообще переживет деплой?».
Как выбрать подрядчика по веб-разработке
Спрашивать подрядчика только про фреймворк — всё равно что выбирать автомобиль по марке шин. Важно, но далеко не главное. React, Vue, Laravel, Symfony и PostgreSQL сами по себе ничего не расскажут о том, насколько хорошо будет спроектирована система.
Гораздо полезнее спросить, что команда хочет выяснить до оценки проекта. Если после получасового разговора о системе с ERP, CRM, личными кабинетами и миграцией данных подрядчик уже готов назвать точную сумму — перед вами либо экстрасенс, либо будущий счёт за дополнительные работы.
Следующий хороший вопрос: какие части системы подрядчик оставил бы нетронутыми. Команда, которая на любую задачу предлагает заказную разработку, умеет продавать часы. Сильная инженерная команда экономит заказную разработку для тех частей, где специфика бизнеса действительно требует собственного решения.
Стоит спросить, что произойдёт, если отвалится 1С или внешний API. Этот вопрос быстро показывает глубину инженерного мышления. И ещё важнее заранее выяснить, сможет ли другая команда или инхаус через два года принять проект: где находятся репозитории, документация, CI/CD, тесты, инфраструктура и описание архитектуры. Заказчик должен иметь возможность однажды расстаться с подрядчиком без необходимости расставаться с системой.
Когда пора подключать специалистов
Здесь подойдет простой тест.
Поставьте себе по одному баллу, если:
- - сайт работает с 1С, ERP, CRM, PIM или другими системами;
- - есть личные кабинеты или несколько ролей;
- - внутри выполняются расчёты или бизнес-правила;
- - данные дублируются;
- - крупные изменения страшно выпускать;
- - команда постоянно упирается в ограничения платформы;
- - ошибка сайта влияет на продажи или операционную работу;
- - никто уже не может быстро объяснить, как всё связано.
0–2 балла. Скорее всего, всё нормально. Не ищите себе дорогих приключений.
3–4 балла. Технический аудит имеет смысл провести до следующего большого этапа развития.
5–8 баллов. У вас уже есть веб-система. Возможно, единственное, чего у неё пока нет, — документа с описанием архитектуры.
Если в тесте набралось больше четырёх баллов, пора оценивать, сколько бизнеса держится на текущей конструкции и где она может сломаться.
Мы в SVK.Digital делаем заказную разработку для бизнеса уже 25 лет и регулярно сталкиваемся с такими проектами — начинаем с разбора архитектуры: вместе с аналитиком и пресейл-инженером собираем карту систем, данных, интеграций и ограничений, находим узкие места и определяем, что можно сохранить, а что пора переделывать. Появляется дорожная карта, приоритеты, сроки и бюджет.
Ну а дальше приступаем к работе: приводим систему в порядок, дорабатываем архитектуру и функционал, настраиваем интеграции, тестируем, пишем документацию, стабилизируем после релиза и при необходимости передаем систему инхаус-команде вместе со знаниями. Всё это — в понятные сроки и по зрелому SDLC.
