1. Позиционирование продукта для публичного рынка

Nimbus — облачная SaaS‑платформа для автоматизации управления жилищно‑коммунальным хозяйством (ЖКХ). Мы закрываем полный цикл работы управляющей компании: от учёта домов, помещений и собственников до начислений по ПП 354, платежей, пеней и прозрачного журнала проводок (Ledger) по каждому лицевому счёту.

Целевая аудитория:

• средние и крупные управляющие компании (100+ домов);
• ТСЖ / ЖСК, у которых есть потребность «выйти из Excel и самописных 1С‑конфигураций»;
• региональные и федеральные холдинги в сфере ЖКХ.

Рынок:

• десятки тысяч УК и ТСЖ в РФ;
• миллионы лицевых счетов и платежей ежемесячно;
• устаревшие on‑prem решения без прозрачного аудита и современной архитектуры.

Nimbus позиционируется как enterprise‑уровневый облачный биллинг ЖКХ с архитектурой, способной выдержать аудит «Большой четвёрки» и требования публичного рынка.

2. Инвестиционная привлекательность

2.1. SaaS‑модель и экономика

• Модель монетизации: подписка (SaaS) + платёжные/транзакционные комиссии + консалтинг/внедрение.
• Предсказуемая выручка: MRR/ARR с высоким LTV благодаря глубокой интеграции в процессы УК.
• Низкий churn: смена биллинга в ЖКХ — дорого и рискованно; после успешного внедрения платформа становится «системой жизни» компании.

2.2. Рынок PropTech и ЖКХ

• цифровизация ЖКХ — приоритет государства и регионов;
• существующие игроки ориентированы либо на документооборот, либо на классический биллинг, но не на прозрачную финансовую архитектуру уровня аудита;
• дефицит современных решений с открытыми API, понятной инфологией и прозрачным журналом проводок.

2.3. Снижение издержек УК

Nimbus позволяет:

• сократить операционные расходы за счёт:
  • автоматизации начислений по ПП 354 (вместо ручных расчётов);
  • автоматического учёта платежей и взаиморасчётов;
  • отказа от самописных Excel/1С‑надстроек и легаси‑баз;
  • автоматического парсинга банковских выписок в текстовом формате 1С (клиент‑банк) и прямых API‑интеграций с банками;
  • двусторонней интеграции с ГИС ЖКХ (выгрузка начислений и загрузка оплат) вместо ручного сверления данных в нескольких системах;
• снизить количество ошибок в квитанциях и претензий жильцов;
• ускорить подготовку отчётности (в т.ч. для ГИС ЖКХ и собственников/советов домов).

3. Технологический ров: Ledger и неизменяемая история

Главный технологический актив Nimbus — финансовое ядро, построенное вокруг журнала проводок (Ledger):

• все движения по ЛС (начисления, оплаты, пени, сторно) фиксируются как иммутабельные записи в таблице ledger_entries (только INSERT, без UPDATE/DELETE);
• баланс по ЛС (account_balances) — производная от Ledger, может быть восстановлен пересчётом;
• используется модель двойной записи: каждое изменение долга по сути представляется парой «дебет/кредит» в домене ЖКХ;
• пени рассчитываются на основе исторического справочника ставок (penalty_rates) и правил ПП 354 для каждого дня просрочки.

Поверх Ledger‑ядра Nimbus формирует три ключевых направления технологического рва:

• Финансовый хаб для УК (банки + платёжные системы).
  • модуль Bank Integrator, умеющий работать как с текстовым форматом 1С (клиент‑банк), так и с прямыми API‑интеграциями с банками;
  • автоматическая загрузка выписок, парсинг и сопоставление с ЛС, генерация проводок в Ledger без ручного ввода;
  • резкое сокращение FTE, занятых на ручной обработке банковских файлов и сверках.
• Compliance‑контур: ГИС ЖКХ как «первый гражданин» архитектуры.
  • двусторонний обмен: выгрузка начислений/объектов и загрузка оплат/статусов;
  • синхронизация справочников и учёт регуляторных требований в доменной модели;
  • снижение регуляторных рисков и стоимости соответствия требованиям надзора.
• Экосистема коммуникаций с жильцами через Messenger MAX.
  • встроенный в дашборды и карточки ЛС мессенджер MAX (виджет/iframe/API) для контакта с жильцами;
  • единое окно для работы с дебиторской задолженностью (от просмотра долга до отправки сообщения в мессенджер);
  • рост собираемости платежей за счёт проактивных и персонализированных коммуникаций (B2B2C‑сценарий).

Что это даёт с точки зрения инвестора и аудита:

• неизменяемая история операций по каждому лицевому счёту;
• возможность воспроизвести состояние долга на любую дату;
• техническая основа для автоматизированного аудита и проверки выборок;
• разделение доменной модели (core-service) и финансовой (billing-service): изменение справочников не нарушает целостность Ledger.

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

4. Архитектура, готовая к аудиту «Большой четвёрки»

Текущая микросервисная архитектура Nimbus закладывает фундамент под аудит больших консалтинговых и аудиторских фирм:

• разделение зон ответственности:
  • nimbus_auth — идентификация, роли, токены;
  • nimbus_core — организации, дома, помещения, ЛС, справочники;
  • nimbus_billing — расчёты, пени, Ledger, балансы;
• явная инфологическая модель (см. docs/architecture/infology.md);
• строгая схема данных для финансовых сущностей:
  • ledger_entries — только добавление, с временными метками и ссылкой на первичные документы (charge:123, payment:456);
  • account_balances — обновляется в тех же транзакциях, что и Ledger, с защитой от гонок (SELECT FOR UPDATE);
• трассировка изменений через миграции БД и сервисные версии.

Такой стек:

• упрощает процедуру due diligence со стороны инвесторов;
• снижает риск «чёрных ящиков» в биллинге при подготовке к листингу;
• позволяет строить поверх основного ядра дополнительные сервисы (BI, отчётность, риск‑аналитику), не нарушая целостность основного учёта.

5. Дорожная карта к IPO (высокоуровневое видение)

Этап 1. Продуктовое и архитектурное созревание

• закрепление архитектуры Ledger как единственного источника истины по долгам;
• покрытие ключевых сценариев УК: массовые начисления, перерасчёты, работа с долгами и пенями;
• расширение API и документации для интеграций.

Этап 2. Масштабирование и операционная зрелость

• выход на стабильный показатель MRR/ARR и прогнозируемый рост;
• стандартизация процессов внедрения (templatized onboarding для новых УК);
• формализация процессов информационной безопасности и управления доступами.

Этап 3. Подготовка к публичному рынку

• аудит финансовой отчётности (МСФО) за несколько лет с опорой на данные Ledger;
• независимая оценка архитектуры и внутренних контролей со стороны внешних консультантов;
• формирование прозрачной истории роста метрик (количество ЛС, объём начислений, собранные платежи и т.п.);
• формулировка публичного нарратива: Nimbus как стандарт де‑факто облачного биллинга ЖКХ с аудит‑готовой архитектурой.

Эта стратегия делает Nimbus кандидатом на IPO не только как очередной SaaS‑продукт, а как технологическую платформу учёта и прозрачности в сегменте ЖКХ, где исторически доминировали закрытые и трудноаудируемые системы.