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

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

Вопрос в том, хватает ли готового решения или нужна своя архитектура. Для руководителей ИТ в крупных компаниях это стратегическое решение: платформа должна соответствовать процессам не только в моменте, но и на годы вперед.

Веб-сервис — это цифровой продукт с бизнес-логикой. В нем происходят операции: пользователь подает заявку, система маршрутизирует ее по ролям, статусы меняются, данные перетекают между системами. Пример — Госуслуги. Это не просто сайт с информацией, а инструмент, в котором государство и гражданин выполняют совместные операции. Другие примеры: банк-клиент, дилерский портал, система согласования договоров, кабинет партнера.

Готовая платформа — SaaS или коробочное решение для класса задач. Bitrix24 закрывает CRM и внутренние коммуникации, ServiceNow — ITSM и сервисные процессы, SAP — ERP-контур, amoCRM — воронку продаж, 1С — бухгалтерию и управленческий учет, HRlink — кадровый электронный документооборот. Их внедряют: настраивают в рамках возможностей платформы.

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

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

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

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

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

Задачи, в которых кастомная архитектура дает очевидное преимущество перед готовым решением:

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

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

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

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

Чек-лист помогает быстро оценить, насколько задача укладывается в готовую платформу. Два-три совпадения — сигнал считать полную стоимость владения.

Быстрый способ структурировать разговор между бизнесом и ИТ.

Вопрос 1. Можно ли описать процесс в терминах платформы без исключений и обходных схем?

Если нет — архитектуры не совпадают.

Вопрос 2. Стоимость кастомизаций платформы за последний год меньше стоимости ее сопровождения?

Если нет — экономика платформы работает против вас.

Вопрос 3. Роадмап вендора совпадает с развитием вашего процесса на два-три года вперед?

Если нет — вы будете тянуть платформу в сторону, на которую она не рассчитана.

Два ответа «нет» из трех — сигнал считать полную стоимость владения и сравнивать с кастомной разработкой.

Кастом дает контроль и точную настройку процессов. Обратная сторона — больше участия заказчика, дисциплины в постановке задач и ответственности за изменения. Это точнее под задачу, но требует большей вовлеченности со стороны бизнеса.

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

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

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

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

Можно ли разрабатывать кастомный веб-сервис поэтапно?

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

Когда готовая платформа точно достаточна?

Когда задача типовая и не предполагает уникальной бизнес-логики: корпоративный сайт, базовый портал для сотрудников, воронка продаж, ITSM-процессы без нестандартных маршрутов. Если процесс укладывается в типовую модель платформы без исключений — готовое решение закрывает задачу быстро и экономично. Проблемы начинаются, когда на типовую платформу начинают надстраивать нетиповую операционную логику. Хороший ориентир: если при описании процесса не возникает фраз «но у нас это работает иначе» или «кроме случаев, когда» — платформы, скорее всего, хватит.

Что делать, если платформа уже внедрена, но не справляется?

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

Как обосновать бюджет на выбор кастома?

Считайте не стоимость разработки, а стоимость текущих обходов: сколько человеко-часов тратится на ручные операции, сколько стоит каждая доработка платформы, какой риск несет зависимость от вендора. Кастом — это не «дорого», это предсказуемо дорого на старте и управляемо в развитии, если процесс сложный. Финансовому директору важна не архитектура, а предсказуемость расходов: покажите, сколько стоили последние три изменения в платформе и как эта цифра менялась год к году. Тренд роста стоимости изменений — самый убедительный аргумент.

Кастомный веб-сервис всегда дороже готовой платформы?

На старте — почти всегда да. Кастомная разработка требует предпроектного анализа, проектирования архитектуры и более длинного цикла. На горизонте двух-трех лет картина меняется. Если процесс сложный, интеграций много и требования регулярно меняются, совокупная стоимость платформы догоняет и превышает кастом за счет накопленных доработок и обходных решений. Для простых задач платформа остается дешевле на всем горизонте. Ключевой вопрос не «что дешевле», а «где находится точка пересечения стоимостей» — и у каждого процесса она своя.

Какая самая частая ошибка при выборе?

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

Можно ли совмещать готовую платформу и кастомные модули?

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