Заказная веб-разработка позволяет создавать веб-приложения и сервисы под конкретные бизнес-процессы: от корпоративных порталов и личных кабинетов до систем автоматизации и высоконагруженных платформ. В таких проектах приходится решать задачи, для которых возможностей готовых продуктов недостаточно: выстраивать собственную бизнес-логику, объединять данные из разных источников, учитывать ограничения внешних систем и требования к дальнейшему развитию.
При этом сложность разработки не всегда заметна в интерфейсе. За несколькими экранами личного кабинета могут стоять десятки интеграционных сценариев, нестандартные правила расчётов и требования к отказоустойчивости.
На примере трёх проектов SVK.Digital разберём, какие инженерные задачи возникают при заказной разработке веб-приложений, как выбираются технические решения и что получает бизнес.
Какие задачи решает заказная веб-разработка
Заказные веб-приложения используют для автоматизации внутренних процессов, взаимодействия с клиентами и партнёрами, управления данными и создания цифровых продуктов.
В зависимости от задач это могут быть:
- - Корпоративные веб-системы и B2B-порталы: каталоги, личные кабинеты дилеров, персональные цены, документооборот, интеграции с ERP и CRM.
- - Системы автоматизации: HRM, WFM, учётные системы, платформы управления заказами, производственными и операционными процессами.
- - Клиентские веб-сервисы: билетные платформы, маркетплейсы, системы бронирования, сервисы подписки и другие продукты с собственной бизнес-логикой.
- - Высоконагруженные веб-приложения: системы с большим количеством одновременных операций, критичными интеграциями и повышенными требованиями к доступности.
Границы между этими категориями часто пересекаются. Например, B2B-портал может одновременно выполнять функции интернет-магазина, личного кабинета и системы документооборота. А внутренний инструмент автоматизации со временем способен превратиться в самостоятельный коммерческий продукт.
В каждом случае архитектуру определяют особенности процессов, данных и существующей инфраструктуры. Именно поэтому похожие по интерфейсу приложения могут принципиально отличаться по сложности разработки.
На примере трёх проектов покажем, где скрывается реальная сложность заказной веб-разработки, как она влияет на архитектуру и почему от принятых решений зависят стоимость и дальнейшее развитие системы.
«Аэролайф»: заказная веб-разработка для сложного корпоративного каталога
«Аэролайф» — российский производитель оборудования для очистки и обеззараживания воздуха. Компания работает с медицинскими учреждениями, промышленными предприятиями, фармацевтическими производствами и коммерческой недвижимостью.
На момент начала проекта у заказчика уже существовал корпоративный сайт с каталогом оборудования и технической информацией. Однако бизнес вырос, появились новые направления, а структура сайта перестала соответствовать потребностям разных аудиторий.
Владельцу медицинского учреждения нужно подобрать оборудование под конкретный объект. Проектировщику — найти характеристики, сертификаты, паспорта изделий и спецификации. Специалисту по закупкам — изучить определённую модель и получить необходимые документы.
Одна и та же информация должна быть доступна через разные пользовательские сценарии. Именно здесь возникла основная инженерная задача.
Как организовать сложные данные без дублирования
Представим сертификат соответствия, который относится сразу к нескольким моделям оборудования. Его необходимо показать в карточках этих моделей, в отраслевых разделах, общей базе документации и разделе для проектировщиков.
Если хранить отдельную копию сертификата в каждом разделе, любое обновление потребует ручной замены нескольких файлов. По мере роста каталога увеличиваются трудозатраты и риск появления устаревших документов.
Аналогичная проблема возникает с оборудованием. Одна модель может использоваться в нескольких отраслях и подходить для разных задач. Жёсткая структура каталога постепенно обрастает повторяющимися разделами и сложными правилами публикации.
Мы переработали информационную архитектуру сайта и реализовали перекрёстные связи между оборудованием, технической документацией и отраслевыми разделами.
Документ загружается в систему один раз, после чего используется во всех связанных разделах. При его обновлении изменения становятся доступны в соответствующих карточках и подборках.
Для разных типов пользователей создали собственные сценарии навигации. B2B-заказчики могут выбирать оборудование по отрасли и области применения. Инженеры и проектировщики получили специализированные разделы с техническими материалами.
Что получил заказчик
Новый сайт объединил каталог оборудования, отраслевые решения, информацию о технологиях и техническую документацию. При этом управление связанными материалами стало проще: редакторам больше не требуется поддерживать несколько экземпляров одного документа.
Ключевое инженерное решение проекта — модель организации данных. Она позволяет развивать каталог, добавлять оборудование и новые отраслевые разделы без постоянного усложнения администрирования.
Этот подход актуален для производителей с большим ассортиментом, B2B-каталогов и корпоративных систем, где одна информация используется в нескольких бизнес-процессах.
Подробный кейс разработки сайта «Аэролайф».
HR-платформа: интеграция с HeadHunter, ограничения API и собственная бизнес-логика
Следующий пример — веб-приложение для автоматизации рекрутинга, которое мы начали разрабатывать для собственного HR-отдела, а затем превратили в отдельный продукт.
Проблема была вполне практической: на одну вакансию приходило больше 600 откликов. Значительная часть кандидатов не соответствовала требованиям, но рекрутеру всё равно приходилось открывать резюме, изучать опыт и проверять навыки.
Мы решили создать систему, которая получает отклики из HeadHunter, анализирует кандидатов с помощью языковой модели и формирует список по степени соответствия вакансии.
Первый прототип позволил проверить гипотезу. Для полноценной эксплуатации потребовались интеграция с HeadHunter, собственная модель оценки и интерфейс для работы с результатами.
Когда внешнее API определяет архитектуру
Основная сложность возникла при получении резюме.
В отклике HeadHunter содержится лишь часть информации. Для полноценной оценки система должна отдельно загрузить резюме с опытом работы, навыками, образованием и другими сведениями.
При этом HeadHunter учитывает получение резюме через API как просмотр. Для используемого аккаунта работодателя действовал лимит в 500 просмотров в сутки.
Теперь представим вакансию с 600 откликами. Если автоматически загрузить первые 500 анкет, суточный лимит будет исчерпан. После этого HR не сможет открывать новые резюме в HeadHunter до обновления ограничения.
Мы учли этот механизм при проектировании интеграции. Перед синхронизацией портал предупреждает пользователя о лимите, позволяя контролировать количество загружаемых анкет.
Полученные резюме сохраняются внутри системы. Поэтому после изменения требований вакансии можно повторно рассчитать рейтинг кандидатов, используя уже загруженные данные.
Как реализовали собственную модель оценки
Для каждой вакансии HR задаёт обязательные и желательные требования, стоп-факторы, описание роли и веса критериев.
Например, обязательные навыки могут формировать до 25% итогового рейтинга, а отсутствие стоп-факторов — ещё 15%. Конкретные значения устанавливает работодатель.
Система передаёт языковой модели резюме, описание вакансии и критерии отбора. В ответ получает рейтинг соответствия от 0 до 100% и пояснения по отдельным параметрам.
Рекрутер видит, какие требования кандидат выполняет, где обнаружены расхождения и по каким пунктам недостаточно информации. После этого может самостоятельно принять решение о следующем этапе отбора.
Стоимость одного анализа в используемой конфигурации составляет примерно 1–5 рублей в зависимости от объёма резюме и параметров запроса.
Что изменилось после внедрения
Раньше первичная оценка 500 резюме занимала у HR больше четырёх часов. Теперь система автоматически расставляет кандидатов по приоритету, а специалист сосредотачивается на 10–15% наиболее подходящих анкет.
Веб-приложение объединило несколько компонентов: данные HeadHunter, собственную бизнес-логику, настраиваемые критерии и интеграцию с языковой моделью.
Главное инженерное решение — организация работы с внешними данными и собственной моделью оценки. При проектировании пришлось учитывать ограничения API, повторное использование информации и возможность объяснить результат автоматической обработки.
Подобные задачи возникают при разработке CRM, корпоративных порталов, финансовых сервисов и других систем, которые зависят от внешних платформ.
Подробный кейс HR-платформы с ИИ-скорингом.
Билетная платформа: заказная разработка высоконагруженного веб-сервиса
Третий проект — билетный виджет для одной из крупнейших билетных систем в России. Он позволяет театрам и организаторам продавать билеты через собственные сайты, сохраняя связь с основной билетной системой.
Организаторы используют разные CMS и технологические платформы. Поэтому мы разработали универсальный встраиваемый виджет, который можно подключить к существующему сайту.
Первую MVP-версию выпустили за четыре месяца. Позже продукт вырос до полноценной системы с интерфейсом покупки билетов, личным кабинетом организатора, административной частью и интеграциями с платёжными сервисами.
Одной из самых сложных задач стала работа системы во время пикового спроса.
Почему дополнительные серверы не решили проблему
Во время старта продаж популярного спектакля множество пользователей одновременно открывают схемы залов, выбирают места и оформляют заказы.
Часть операций выполняется через синхронные обращения к внешнему SOAP-шлюзу театра. У некоторых площадок этот шлюз дополнительно передаёт запросы другой билетной системе.
Пока внешний сервис обрабатывает запрос, PHP-воркер нашего приложения ожидает ответа. Если шлюз начинает тормозить, время ожидания увеличивается, а количество одновременно занятых воркеров растёт.
Во время одного из инцидентов тайм-аут внешнего вызова увеличили с 7 до 15 секунд. Это не помогло: воркеры дольше оставались занятыми. Увеличение лимитов PHP-FPM и PostgreSQL тоже не устранило ограничение.
В марте 2026 года при старте продаж МХТ нагрузка достигла 578 соединений в секунду к PHP-FPM. При этом процессоры, память и база данных на нашей стороне работали без аномалий. Ошибки продолжали поступать от внешнего шлюза театра.
Диагностика показала, что система упирается в ограничение, находящееся за пределами нашей инфраструктуры.
Одновременно обнаружились внутренние проблемы, которые мешали эффективно распределять трафик между несколькими серверами.
Как подготовили приложение к горизонтальному масштабированию
Ранее часть состояния приложения хранилась локально: файловый кеш, сессии и блокировки. Из-за этого дополнительная нода не могла полноценно обрабатывать все пользовательские сценарии.
Мы перенесли файловый кеш и сессии в Redis и переработали маршрутизацию всех 73 методов API. После изменений запросы конкретного театра стало возможно полностью направлять на отдельную ноду.
Ещё одна проблема находилась во фронтенде. Билетный виджет работает внутри iframe на сайтах организаторов. Из-за ограничений сторонних cookie браузер мог создавать новую сессию при каждом открытии виджета, вызывая дополнительные 3–5 запросов.
Мы изменили механизм хранения сессии, использовали localStorage и организовали обмен данными через postMessage. Это позволило устранить зависимость от сторонних cookie.
Почему выбрали ограниченный объём изменений
При анализе системы мы рассматривали более масштабную модернизацию: очереди, переработку интеграций, улучшение наблюдаемости и другие архитектурные задачи.
Полную программу выхода из накопленных ограничений оценили примерно в 890 часов. Однако ближайший старт продаж требовал более быстрого решения.
Поэтому мы сосредоточились на переносе состояния и изоляции трафика. Непосредственная разработка заняла около 30–40 часов, а весь процесс от анализа до выпуска изменений — примерно шесть недель.
С апреля по август 2026 года старты продаж прошли без новых инцидентов. Приложение получило возможность работать на нескольких нодах с изоляцией трафика отдельных театров.
Главное инженерное решение — устранение конкретных ограничений, которые мешали распределять нагрузку. Это позволило подготовить систему к дальнейшему развитию без немедленной реализации всей программы модернизации.
Подробный технический разбор — в статье «Как подготовить веб-сервис к высокой нагрузке и не переплатить».
Пример разработки билетного виджета для другой билетной системы.
Что определяет архитектуру заказного веб-приложения
Три проекта показывают разные источники сложности.
В «Аэролайф» ключевое значение имела организация данных и связей между ними. В HR-платформе — интеграция с внешним сервисом и собственные правила обработки информации. В билетной системе — производительность, управление состоянием приложения и работа с инфраструктурными ограничениями.
Поэтому архитектуру заказного веб-приложения начинают проектировать с анализа критических процессов.
Например, компания хочет разработать B2B-портал с каталогом, личными кабинетами дилеров и оформлением заказов.
На первый взгляд задача понятна. Но для проектирования потребуется выяснить, где хранятся ассортимент, цены и остатки, кто управляет договорами, как рассчитываются индивидуальные условия и что происходит при недоступности ERP.
Если система создаёт заказ при каждом повторном запросе, нестабильная интеграция может привести к дублированию операций. Если данные об остатках обновляются с задержкой, необходимо определить, когда можно подтверждать заказ и резервировать товар.
Параллельно возникают требования к безопасности, разграничению прав, аудиту действий и производительности.
Каждый из этих вопросов влияет на модель данных, состав компонентов и стоимость разработки.
Готовые решения при этом могут оставаться частью архитектуры. Например, компания продолжает использовать действующую ERP, а заказная разработка охватывает клиентский портал и интеграционный слой. Такой вариант позволяет сохранить существующие инвестиции и ограничить объём нового проекта.
Из чего складываются стоимость и сроки заказной веб-разработки
Стоимость разработки веб-приложения зависит от сложности бизнес-логики, количества интеграций, модели данных, требований к безопасности, нагрузке и дальнейшему сопровождению.
Два продукта с похожими интерфейсами могут требовать разного объёма работ.
Представим личный кабинет, где клиент просматривает каталог и оформляет заказ.
В простой реализации цены фиксированы, остатки хранятся в одной базе, а заказ создаётся непосредственно внутри приложения.
В более сложной системе цена зависит от договора, остатки поступают из нескольких складов, требуется согласование заказа, а документы формируются в 1С. При оформлении необходимо учитывать доступность внешних сервисов, повторные обращения и возможность восстановления незавершённых операций.
Визуально два кабинета могут почти не отличаться. Но во втором случае потребуется больше аналитики, интеграционной разработки и тестирования.
На итоговый бюджет влияют несколько составляющих:
- - Аналитика и проектирование: бизнес-процессы, требования, пользовательские сценарии, модель данных и архитектура.
- - Разработка: интерфейсы, серверная логика, административная часть и интеграции.
- - Тестирование: проверка функций, взаимодействия компонентов, безопасности и производительности.
- - Запуск и сопровождение: инфраструктура, развёртывание, мониторинг, документация и дальнейшее развитие.
На предварительной оценке важно отдельно фиксировать допущения и технические риски. Например, возможность интеграции может зависеть от документации стороннего API, доступных методов и ограничений поставщика системы.
Если эти условия неизвестны, потребуется дополнительное обследование или технический прототип.
Разработку также можно разделить на этапы: сначала реализовать критические бизнес-сценарии, затем добавлять новые функции и интеграции. Такой подход помогает управлять бюджетом и проверять решения до дальнейшего масштабирования.
Подробнее о составе расходов мы рассказывали в материале «Сколько стоит разработка веб-приложения».
Как выбрать подрядчика по заказной веб-разработке
При выборе компании-разработчика стоит изучать проекты, сопоставимые с вашей задачей по инженерной сложности.
Для корпоративного портала важен опыт работы со сложными данными и интеграциями. Для системы автоматизации — понимание бизнес-процессов и требований к эксплуатации. Для высоконагруженного веб-сервиса — способность диагностировать ограничения производительности и проектировать устойчивую архитектуру.
Показательны кейсы, в которых подрядчик объясняет конкретные технические решения, обнаруженные ограничения и результаты работы.
На предварительных встречах полезно выяснить, как команда исследует существующую инфраструктуру, оценивает интеграции, выявляет технические риски и выбирает архитектуру.
Отдельный вопрос — дальнейшая судьба продукта. Заказчику важно заранее согласовать права на исходный код, доступ к инфраструктуре, состав документации, порядок сопровождения и возможность передачи системы внутренней команде.
По итогам обследования желательно получить понятное описание границ проекта, основных технических решений, интеграций, этапов и предварительного бюджета. Такой документ позволяет сравнивать предложения подрядчиков по составу работ и оценивать последствия выбранных решений.
Когда заказная веб-разработка оправдана
Создание собственного веб-приложения требует инвестиций в разработку, инфраструктуру и сопровождение. Поэтому решение стоит принимать с учётом существующих инструментов и задач бизнеса.
Для типовых процессов часто достаточно готовой платформы. Собственная разработка становится оправданной, когда компании требуется специфическая бизнес-логика, глубокая интеграция с корпоративными системами или возможности, которые существующие продукты ограничивают.
При этом объём проекта может быть разным. Иногда достаточно создать отдельный сервис интеграции или личный кабинет поверх действующей системы. В других случаях потребуется самостоятельная веб-платформа с собственной моделью данных, интерфейсами и серверной логикой.
Опыт «Аэролайф», HR-платформы и билетной системы показывает, насколько разные инженерные задачи могут скрываться за понятием заказной веб-разработки. В каждом проекте результат зависел от понимания бизнес-процессов, существующих ограничений и выбора технического решения, соответствующего задаче.
В SVK.Digital мы занимаемся заказной веб-разработкой для бизнеса: создаём корпоративные системы, личные кабинеты, B2B-порталы и веб-сервисы, реализуем интеграции, модернизируем существующие продукты и помогаем передавать проекты внутренним командам.
Если вы планируете разработку нового веб-приложения или развитие действующей системы, обсудите задачу с нашим пресейл-инженером и аналитиком. На встрече разберём требования, существующую инфраструктуру, основные ограничения и возможные варианты реализации. Определим этапы работ и подход к оценке сроков и бюджета.
