Короткий ответ: бизнес-приложение живёт на связках — минимальный контур почти всегда включает платежи с фискализацией, синхронизацию с учётной системой или CRM и уведомления; аналитика обязательна с первого дня. Трудоёмкость интеграции определяется не её названием, а качеством чужого API: современная система подключается за дни, учёт без документированного API — через промежуточные обмены и недели. Ниже — карта типовых интеграций и порядок подключения.
Минимальный контур первой версии
Приложение, которое не обменивается данными с вашими системами, — игрушка: заказы из него переписываются руками, остатки врут, клиенты дублируются. Поэтому минимальный контур первой версии: платежи, синхронизация с учётом (заказы, клиенты, остатки или расписание) и уведомления. Всё остальное — вторая очередь по принципу MVP. Наша практика — на странице интеграций и автоматизации.
Платежи и учёт
Приём платежей. Онлайн-оплата картой, СБП, рассрочки, рекуррентные платежи для подписок — плюс фискализация чеков по 54-ФЗ, если вы торгуете в России: чек должен формироваться автоматически, а не руками бухгалтера. Юридические формулировки о расчётах — с вашим юристом; техническую часть (касса, возвраты, сверка) мы берём на себя.
Учётная система и CRM. Типовые связки: из учёта в приложение — каталог, цены, остатки, расписание; из приложения в учёт — заказы, записи, оплаты, данные клиентов. Двусторонняя синхронизация важнее красивого интерфейса: именно она убирает ручную работу менеджеров. Если CRM у вас внедрена, в неё должны падать лиды и события приложения — иначе вы получите две разрозненные базы.
Уведомления и аналитика
Уведомления — канал возврата: push о статусе заказа, напоминание о записи, сообщение о брошенной корзине. Проектируем каскадом: push → сообщение в мессенджер → SMS/email для критичных событий, с ограничением частоты, чтобы канал не выгорел. Аналитика — не интеграция «на потом»: события и воронки собираются с первого дня, иначе первые месяцы продукта останутся без данных. Карта событий — в статье об аналитике приложения.
Как оценивается трудоёмкость интеграции
Правило: цена интеграции — в качестве чужого API. Три сценария. Современная система с документацией и тестовым контуром: подключение — дни, риски минимальны. Система с API, но без документации: недели на исследование методом проб. Система без API (старый учёт, самопис): промежуточные обмены файлами или прямой доступ к данным — работает, но требует отдельной оценки и регламента. Перед сметой мы всегда смотрим на вашу систему и честно говорим, какой это сценарий, — это один из главных факторов стоимости и сроков.
И отдельно про внешние сервисы, которые «все подключают»: службы доставки, карты, программы лояльности, телефония. Подключайте их, когда базовый контур стабилен, — каждая внешняя зависимость добавляет продукту точку отказа и абонентскую нагрузку на поддержку.
Калькулятор выручки
Открыть калькуляторКонцепция приложения — бесплатно
Получить концепциюЧастые вопросы
Наша учётная система старая, API нет. Это приговор?
Нет: работают промежуточные обмены — выгрузки по расписанию, промежуточная база, прямой доступ к данным. Это медленнее и требует регламента, но решаемо; честную оценку дадим после знакомства с системой.
Кто отвечает, если «отвалилась» чужая система?
Проектируем деградацию: приложение продолжает принимать заказы и догружается при восстановлении связи, а мониторинг сигналит о сбое. За работоспособность самой чужой системы отвечает её владелец — это фиксируем в схеме ответственности.
Можно ли сначала запуститься без интеграции с учётом?
Можно, если готовы к ручной обработке заказов первые недели — иногда это осознанный план пилота. Но планируйте интеграцию сразу: архитектура под неё закладывается на старте, иначе потом будет дороже.
Что нужно от нас для старта интеграций?
Контакт администратора каждой системы, доступ к документации и тестовому контуру, решения по платёжному провайдеру. Полный список — в чек-листе подготовки.