Кастомные IT-решения

Часто задаваемые вопросы

• Сколько стоит кастомная IT-система и как формируется смета?

  MVP — от 120 000 ₽ за 4–6 недель: базовый функционал, архитектура с заделом на рост, REST API, документация. Полная система — от 300 000 ₽ за 2–3 месяца: сложная бизнес-логика, интеграции с внешними сервисами, масштабирование, админка. Поддержка — от 50 000 ₽/месяц. Смета строится после декомпозиции на сущности (пользователи, заказы, документы…) и use-case (что делает каждая роль). Дёшево — типовая система без интеграций; средне — с 1–3 интеграциями (1С/CRM/платёжки); дорого — со сложными расчётами, биллингом, отчётами, мультитенантностью. Бесплатно собираем ТЗ за 1–2 встречи (60–90 минут каждая) и выдаём смету с разбивкой по спринтам — без обязательств с вашей стороны.

• Когда стоит заказывать кастомную систему, а не коробочное SaaS-решение?

  Кастом нужен, когда: коробка не покрывает 30%+ ваших процессов и кастомизация ограничена; ежемесячная подписка на SaaS превышает 50 000 ₽ и масштабируется с количеством пользователей; есть требования по 152-ФЗ и нельзя хранить данные на серверах вендора (особенно зарубежных); нужна глубокая интеграция с 1С/ERP/учётной системой, которой нет коннектора; продукт сам по себе является источником дохода (вы продаёте функционал). Не нужен: для CRM малого бизнеса (AmoCRM, Bitrix24 закрывают 90%), для интернет-магазина без специфики (Tilda, Insales), для базовой аналитики (Power BI, Metabase). На брифе помогаем определить — иногда честно говорим «вам коробка подойдёт, не тратьте бюджет».

• С какими внешними системами вы интегрируетесь?

  1С (УТ, ERP, Бухгалтерия) — через REST/SOAP/OData или прямой обмен XML, делаем двусторонний обмен (товары, заказы, остатки, контрагенты, документы) с конфигурируемой частотой; AmoCRM, Bitrix24, RetailCRM — через REST API и webhooks; платежи — CloudPayments, Tinkoff, ЮKassa, Stripe для зарубежных; маркетплейсы — Ozon, Wildberries, Yandex.Market через их Seller API; мессенджеры — Telegram Bot API, WhatsApp Business Cloud API, VK Bot; СБИС, Контур.Диадок — для ЭДО; почтовые сервисы — Mindbox, Unisender, SendPulse. Если интеграции с конкретным сервисом нет — пишем под него с нуля, обычно занимает 5–15 дней. Все интеграции выносим в отдельный слой — переключение между провайдерами (например, ЮKassa → Tinkoff) стоит 1–3 дня вместо рефакторинга всей системы.

• Как происходит миграция со старой системы (legacy, 1С, Excel)?

  Сначала аудит: что есть, какие данные, в каких форматах, объём, регулярность изменений. Параллельная работа: новая система запускается рядом со старой, данные синхронизируются ежедневно или real-time, пользователи постепенно переходят. После 2–4 недель параллельной работы старая система отключается. Для одноразовой миграции (Excel, Access, старая 1С) — пишем скрипт переноса с проверкой целостности (контрольные суммы, дубли, валидация), запускаем на тестовом окружении, согласуем расхождения. Никогда не «выдёргиваем рубильник» — это всегда поэтапная замена с возможностью отката. Для legacy-систем с тысячами пользователей миграция — отдельный спринт на 4–8 недель с собственным планом.

• Кому принадлежит код и инфраструктура после сдачи проекта?

  Весь исходный код, схемы базы данных, документация архитектуры, доступы к серверам и сторонним сервисам передаются вам — без зависимости от Raylet. Код лежит в вашем GitLab/GitHub-репозитории (мы получаем доступ как контрибьюторы на время разработки), или в нашем с правом forka и переноса в любой момент. Инфраструктура (серверы Yandex Cloud / VK Cloud / ваш on-premise) оплачивается с вашего аккаунта или нашего с reimbursement-моделью — на выбор. После сдачи проекта можно полностью отказаться от наших услуг и работать со своей командой или другим подрядчиком. Документация архитектуры (ER-диаграммы, OpenAPI, deployment guide) пишется не «для красоты в репорт» — реальный инструмент для новой команды.

• Как обеспечивается безопасность и соответствие 152-ФЗ?

  Базовая защита по умолчанию: HTTPS с TLS 1.2+, защита от типовых атак (SQL injection, XSS, CSRF) через ORM и встроенные механизмы NestJS, rate limiting на API, защита от brute-force на авторизации, code review на каждом MR, обновление зависимостей по расписанию (Dependabot/Renovate), резервное копирование БД ежедневно с retention 30 дней. По запросу — независимый security-аудит перед релизом (стоимость 50–150k ₽, делает партнёр). Для соответствия 152-ФЗ: хостинг на серверах в РФ (Yandex Cloud, VK Cloud, Selectel), оформление документации (Положение об обработке ПДн, согласия пользователей, реестр обработок), уведомление Роскомнадзора. Юр.поддержка по 152-ФЗ — отдельно, через нашего штатного юриста.

• Что делать если нагрузка вырастет в 10–100 раз?

  Архитектуру изначально проектируем с заделом на рост. Базовый стек справляется до 1000 RPS на одном сервере: NestJS + PostgreSQL с правильными индексами + Redis для кэша. Дальше — горизонтальное масштабирование: реплики приложения за балансировщиком nginx, read-реплики PostgreSQL, шардирование при необходимости (>500 GB данных), вынесение тяжёлых задач в очередь (BullMQ, RabbitMQ). Для пиковых нагрузок — Kubernetes с автоскейлингом по CPU/RPS. Тестируем нагрузку на этапе релиза через k6 или Yandex Tank — даём отчёт «выдержит до X пользователей одновременно». При росте трафика прогнозируем точки боли заранее: «при 5000 MAU нужен апгрейд БД на 8 CPU, при 50 000 MAU — read-реплики». Без сюрпризов.