Как мы перестраивали внутреннюю систему в финтехе

Весной 2025 мы завершили проект для организации в секторе финтеха. И хотя в IT-ландшафте клиента уже была внутренняя система планирования, она устарела — как технологически, так и логически. Задача: сохранить ядро, перевести интерфейс в web, добавить десятки новых функций и при этом… не сломать ни одного бизнес-процесса. Работать пришлось как с хирургической точностью, так и в полной изоляции от внешнего мира.

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

Мы развивали систему на базе PostgreSQL и MS SQL с серверными скриптами и кастомными REST API. Компоненты интерфейса писались вручную, а хранилище данных подключалось через защищенную корпоративную платформу. Внедряли модули без внешних фреймворков — в тех условиях это было принципиально.

Что было в фокусе?

• Планирование мероприятий. Не просто календари — а цепочки согласований, напоминания, контроль статусов.
• Ресурсный модуль. От распределения нагрузки и учета занятости до фиксации квалификаций и обучения.
• Работа с документами. Автоматическая генерация, контроль форматов, визуализация в браузере и поддержка ЭП (электронной подписи).
• Информационные блоки. Внутренние справочники, памятки, push-оповещения.
• Аналитика. Синхронизация с хранилищем данных, витрины, отчеты по ключевым метрикам.
• Администрирование. Гибкие роли, управление правами доступа, аудит действий.

Суммарно — 15+ полноценных модулей. Всё — в одной системе. Всё — в соответствии с внутренними стандартами безопасности и ИТ-инфраструктуры.

Ни один модуль не внедрялся “с нуля”. Все изменения накатывались поэтапно. Старые процессы продолжали работать, пока новые тестировались. Так, например, модуль контроля ресурсов запускался в параллель с существующими таблицами — и только после валидации данных стал основным.

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

Потому что сложность бизнеса нельзя уместить в SaaS. Там, где важна отчетность, история изменений, контроль доступа до поля формы — нужны другие инструменты. В госструктурах часто есть внутренние приказы, регламенты, ГОСТы, которым должна соответствовать каждая кнопка.

SaaS — это часто компромисс. Здесь — не было места компромиссам.

После доработки система:

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

Это не “новое ПО”. Это современный скелет под старые, но жизненно важные процессы.

Когда ИТ-ландшафт включает нормативные требования, изоляцию, сложные потоки согласований и высокую ответственность — нет смысла пытаться натянуть SaaS на реальность. Надо проектировать с нуля. В этом кейсе кастомная разработка не была выбором. Она была единственно возможным способом сделать рабочее решение.