Ко мне регулярно приходят с одинаковым запросом: сайт есть, трафик есть, а бизнес всё равно упирается в ручные процессы. Менеджер вбивает заявки в Excel, склад сверяют по телефону, статус заказа клиент узнаёт только через звонок. Вот с этого момента и начинается разработка веб платформы для бизнеса: не очередной лендинг и не магазин на конструкторе, а система, которая работает как отдельный продукт со своей базой данных, ролями пользователей и API для интеграций.
Чем веб-платформа отличается от сайта
Сайт показывает информацию и собирает заявки. Платформа хранит данные, обсчитывает бизнес-логику и меняет поведение в зависимости от того, кто зашёл под своей учёткой. На лендинге на Tilda я могу добавить калькулятор доставки скриптом за пару часов, а вот личный кабинет с историей заказов, ролями «клиент», «менеджер», «склад» и правами на разные разделы туда уже не встроить, конструктор для этого не предназначен.
| Параметр | Сайт | Веб-платформа |
|---|---|---|
| Задача | Показать оффер, собрать заявку | Автоматизировать процессы и хранить данные |
| Данные | Тексты и изображения в CMS | Собственная база данных с моделями и связями |
| Пользователи | Один тип посетителя | Роли с разными правами доступа |
| Логика | Шаблоны и готовые блоки | Код под конкретные бизнес-процессы |
Признаки того, что сайту уже тесно
На практике сигналы почти всегда одни и те же. Заказы из формы на сайте вручную переносят в другую систему, и на этом теряется время и точность. У процесса появляются роли: одному сотруднику нужно видеть все заявки, другому только свои, третьему только статистику. Эквайринг и склад живут отдельно друг от друга: я не раз видел магазины на WooCommerce, где T‑Bank подключен, а остатки на складе никто не синхронизирует, и менеджер продаёт то, чего физически нет.
Ещё один явный признак: логика доставки перестаёт помещаться в конструктор. Зоны доставки для Tilda я обычно донастраиваю скриптом, но когда к тарификации СДЭК добавляются свои правила по весу, региону и типу товара, дешевле и надёжнее вынести это в отдельный сервис с собственным API, а не городить очередной кастомный скрипт поверх чужой платформы.
И последний признак, самый частый: бизнесу нужна автоматизация, которая связывает несколько систем сразу, CRM, склад, бухгалтерию, мессенджеры. Один n8n-сценарий такое покрывает, но когда сценариев становится десяток и они начинают зависеть друг от друга, проще вынести общую логику в свою платформу, а no-code инструменты оставить для второстепенных задач.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Архитектура: из чего состоит собственная система
Платформа для бизнеса обычно состоит из четырёх слоёв, и я стараюсь их не смешивать.
- Фронтенд: интерфейс для сотрудников и клиентов, обычно SPA на React или Vue
- Backend/API: бизнес-логика, авторизация, права доступа, чаще всего на Laravel или Node.js
- База данных: PostgreSQL или MySQL с моделями под реальные сущности бизнеса, а не под шаблон CMS
- Слой интеграций: очереди задач и вебхуки, через которые платформа общается с CRM, эквайрингом, службами доставки и ботами
Простой пример из практики: у одного клиента заявка с сайта должна была одновременно попадать в CRM, ставить задачу на склад и уведомлять ответственного менеджера в Telegram. На бэкенде это выглядит примерно так:
Route::middleware('role:manager')->group(function () {
Route::post('/orders', [OrderController::class, 'store']);
Route::get('/orders/{order}', [OrderController::class, 'show']);
});
Один роут, но за ним стоит проверка роли, запись в базу и рассылка событий во внешние сервисы. В конструкторе сайтов такую цепочку не собрать, а на своём бэкенде это обычная задача на день-два.
Какой стек выбираю под задачу
Стек подбираю под то, кто и как будет пользоваться системой, а не по личным предпочтениям.
Если нужен внутренний инструмент для сотрудников, беру React для CRM или админ-панели: там важны сложные формы, таблицы с фильтрами и права доступа. Для дашбордов и BI-отчётности чаще ставлю Vue.js, он быстрее собирается под визуализацию метрик и графиков. Публичную часть, которую видят клиенты и которая должна хорошо индексироваться, делаю на Next.js, а закрытую часть с личным кабинетом выношу в отдельное SPA поверх того же API.
Бэкенд почти всегда Laravel, если нужна классическая система с ролями, платежами и админкой, либо Node.js, если платформа завязана на реалтайм-события и очереди. Отдельно на этот же API можно посадить бота на aiogram для внутренних уведомлений сотрудникам, ему не нужен свой бэкенд, он просто дергает те же эндпоинты, что и фронтенд.
Интеграции: CRM, платежи, доставка, боты и автоматизация
Платформа редко существует в одиночку, обычно вокруг неё уже есть CRM, эквайринг и служба доставки, и всё это нужно связать. Из свежих кейсов: интернет-магазин на связке WooCommerce и T‑Bank, где нужно было перенести логику расчёта доставки СДЭК с их API на платформу заказчика, чтобы отвязаться от ограничений плагина. Для похожих задач, где процессы упираются в разрозненные таблицы и звонки менеджеров, обычно есть смысл заказать разработку веб-сервиса под конкретные бизнес-процессы, а не наращивать очередной слой доработок поверх сайта.
Для внутренней автоматизации, которая не требует собственной разработки, использую n8n: связка формы на сайте, CRM и таблицы синхронизируется без бэкенда за несколько часов. Но как только сценарий начинает завязываться на права доступа и хранение истории, я переношу его логику в платформу, а n8n оставляю только как связующий слой между внешними сервисами.
Отдельно стоит поддержка клиентов: если заявок много, вместо раздутого штата операторов ставлю чат-бота с базой знаний на Claude API, он отвечает по документации компании и передаёт сложные случаи человеку. Для внутренних процессов, наоборот, чаще хватает обычного aiogram-бота без ИИ, он просто пересылает уведомления и принимает команды от сотрудников.
Сколько стоит и сколько времени занимает разработка
Цены ниже мои собственные, без верхней границы, финальная стоимость зависит от объёма задач и глубины интеграций.
| Задача | Цена | Срок |
|---|---|---|
| Веб-сервис или SaaS под ключ | от 300 000 ₽ | от 8 недель |
| CRM или админ-панель на React | от 100 000 ₽ | от 5 недель |
| API/бэкенд на Laravel | от 100 000 ₽ | от 6 недель |
| Дашборд или BI на Vue.js | от 90 000 ₽ | от 4 недель |
| Telegram-бот с интеграциями | от 30 000 ₽ | от 2 недель |
| Автоматизация в n8n | от 25 000 ₽ | от 1 недели |
| Техподдержка после запуска | от 15 000 ₽/мес | ежемесячно |
На рынке за похожую платформу студии обычно просят в несколько раз больше и растягивают сроки на месяцы согласований, поэтому если бюджет ограничен, я советую стартовать с MVP: закрыть один самый болезненный процесс, например синхронизацию заказов и склада, и уже на реальных данных решать, что достраивать дальше.
Частые вопросы
Сколько времени занимает разработка платформы с нуля?
Зависит от объёма модулей, но минимальный рабочий продукт с одной ролью пользователей и базовым API я обычно собираю за 8-10 недель. Полноценная система с несколькими ролями, интеграциями и админкой занимает от 3-4 месяцев.
Можно ли начать с MVP и дорастить систему потом?
Это мой обычный подход. Беру самый узкий процесс, который сильнее всего мешает бизнесу, например заявки или склад, закрываю его платформой, а остальные модули добавляю по мере того, как становится понятно, что именно нужно автоматизировать дальше.
Чем платформа отличается от готовой CRM вроде Bitrix24 или amoCRM?
Готовая CRM закрывает типовые задачи учёта сделок и звонков, но её логику сложно переписать под нестандартный процесс, и вы платите за лицензии независимо от того, пользуетесь функциями или нет. Своя платформа стоит дороже на старте, зато логика пишется под конкретный бизнес и не упирается в ограничения чужого продукта.
Нужен ли отдельный сервер или подойдёт обычный хостинг?
Обычный виртуальный хостинг для платформы с базой данных и API не подходит, нужен VPS или облачный сервер с доступом к консоли. Для старта хватает недорогого VPS, а нагрузку и масштабирование продумываю уже после того, как продукт подтвердил, что им реально пользуются.