Ко мне обращаются по-разному: одни просят «сайт с личным кабинетом», другие сразу говорят «нужен SaaS». По сути это одно и то же - разработка платформы для онлайн сервиса, где кроме дизайна есть авторизация, роли пользователей, платежи, база данных и API для будущих интеграций. От сайта-визитки такой проект отличается тем, что живет не один раз после публикации, а меняется каждую неделю: добавляются функции, растет нагрузка, подключаются новые сервисы. Разберу, как я собираю архитектуру такого проекта и в каком порядке довожу его до продакшена.
С чего начинается разработка платформы для онлайн-сервиса
Перед тем как открывать редактор кода, закрываю три вопроса: кто пользователь, какие у него сценарии и что случится через полгода после запуска. Платформа для сервиса такси и платформа для B2B-каталога поставщиков технически обе «веб-приложение», но решают разные задачи и требуют разной архитектуры.
На старте фиксирую:
- роли пользователей и что каждая роль может делать - клиент, менеджер, администратор;
- ключевые сценарии от регистрации до оплаты и получения результата;
- внешние системы, с которыми предстоит работать - банк-эквайер, служба доставки, CRM, мессенджеры;
- нагрузку на старте и ожидаемый рост через год.
Дальше выбираю архитектуру. Для проекта с бюджетом до 500 000 ₽ и одной командой разработки почти всегда беру монолит на Laravel или Node.js - его быстрее собрать и дешевле поддерживать. Микросервисы обсуждаю только если у заказчика уже есть несколько независимых команд и разная скорость релизов у частей системы: например, платежный модуль обновляется раз в квартал, а модуль уведомлений - каждую неделю.
Когда конструктора уже недостаточно
Часто ко мне попадают проекты, которые начинались на Tilda: лендинг вырос в интернет-магазин, потом появились скрипты зон доставки и расчета налога, потом захотелось личный кабинет с историей заказов. В какой-то момент кастомные Tilda-скрипты упираются в потолок платформы - авторизация есть только штатная, в модуле Members и личном кабинете магазина, свои роли пользователей с правами под них не завести, а каждая новая интеграция держится на связке из нескольких сторонних сервисов. Это нормальный путь роста, но именно в этот момент есть смысл переходить на платформу с собственным бэкендом, а не наращивать очередной скрипт поверх конструктора.
Технологический стек для веб-сервиса
Стек подбираю под задачу, а не под моду. Для админ-панелей и CRM беру React, для сервисов с большим количеством форм и отчетов - Vue, для бэкенда - Laravel или Node.js в зависимости от того, что будет расти быстрее: бизнес-логика или количество асинхронных операций.
| Слой | Что использую | Когда выбираю именно так |
|---|---|---|
| Бэкенд | Laravel | Много бизнес-логики, отчетов, ролей доступа |
| Бэкенд | Node.js / Express | Много асинхронных операций, вебсокеты, real-time |
| Фронтенд | React | Сложный интерфейс, CRM, дашборд |
| Фронтенд | Vue | Формы, публичная часть сервиса, SEO-страницы |
| Мобильная часть | PWA или адаптивный веб | Бюджет ограничен, нативное приложение не критично на старте |
На MVP-стадии почти всегда советую PWA вместо нативного приложения: экономит недели разработки под iOS и Android отдельно, а после подтверждения спроса нативную версию можно добавить как отдельный этап.
База данных и хранение данных
Для девяти проектов из десяти беру PostgreSQL - она справляется и с транзакциями, и с отчетами, и с JSON-полями, если что-то не укладывается в жесткую схему. MongoDB беру только когда данные сильно неоднородны, например каталог с товарами из десятков источников с разным набором атрибутов.
Redis подключаю для кеша и очередей - без него отправка письма или пуша «в лоб» тормозит основной запрос пользователя. Файлы - фото, документы, экспорт отчетов - храню в S3-совместимом хранилище на серверах в РФ. Персональные данные и переписку с клиентами по 152-ФЗ нельзя размещать в иностранных облаках вроде Google Sheets или Airtable, даже если это кажется временным решением на этапе MVP.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Интеграции: платежи, доставка, уведомления
Почти в каждой платформе есть три типовых интеграции.
Платежи - чаще всего эквайринг T‑Bank, реже ЮKassa. Если сервис вырос из интернет-магазина на WooCommerce, синхронизирую заказы через REST API, чтобы не переписывать логику оплаты с нуля.
Доставка - для сервисов с физическими товарами подключаю API СДЭК: расчет стоимости и сроков на этапе оформления заказа, статусы посылки в личном кабинете клиента.
Уведомления - вместо email, который открывают через раз, ставлю Telegram-бота на aiogram: сообщения о статусе заказа, новых заявках и ошибках в системе долетают за секунды, а не сутки.
Отдельно - внутренняя автоматизация. Через n8n связываю CRM, таблицы и мессенджеры без написания отдельного бэкенда под каждую мелкую задачу: например, карточка сделки в CRM создается автоматически при оплате, а менеджеру приходит уведомление, если клиент не заходил в кабинет неделю.
Инфраструктура, деплой и масштабирование
Деплой собираю через CI/CD - GitHub Actions или GitLab CI, чтобы код проходил тесты и линтер до попадания на прод, а не после жалобы пользователя. Приложение упаковываю в Docker: окружение на сервере совпадает с тем, что было у разработчика, и не возникает ситуации «у меня работало».
Сервер беру в РФ - Selectel, Timeweb Cloud или VK Cloud, в зависимости от бюджета и нужных мощностей. Для сервиса с нагрузкой до нескольких тысяч пользователей в сутки хватает одного VPS с базой и приложением на нем же. Дальше разношу базу данных на отдельный сервер, добавляю балансировщик и второй инстанс приложения.
Мониторинг - Sentry для ошибок в коде, Grafana с Prometheus или встроенные метрики хостинга для нагрузки на сервер. Без этого о проблеме узнаешь от клиента в поддержке, а не из дашборда за пять минут до жалобы.
Резервные копии базы данных настраиваю с первого дня - ежедневный бэкап с хранением за 30 дней спасал не один проект после кривого миграционного скрипта или случайной ошибки в консоли. HTTPS через Let’s Encrypt, ограничение частоты запросов на публичных эндпоинтах и логирование действий администраторов - три вещи, которые добавляю в любой проект вне зависимости от бюджета, потому что цена доработки на старте в разы ниже цены разбора инцидента после запуска.
Порядок запуска: этапы и сроки
| Этап | Что делаю | Срок |
|---|---|---|
| Проектирование | Требования, архитектура, прототип интерфейса | 1-2 недели |
| Разработка MVP | Базовый функционал, авторизация, основной сценарий | 4-6 недель |
| Интеграции | Платежи, доставка, уведомления, CRM | 2-3 недели |
| Тестирование | Ручное и автотесты ключевых сценариев | 1-2 недели |
| Запуск и поддержка | Деплой на прод, мониторинг, доработки по фидбеку | от 1 недели |
Сроки в таблице - для платформы среднего размера: одна-две роли пользователей, три-четыре внешние интеграции. Проект с десятком ролей и собственным API для партнеров считаю отдельно, обычно это плюс 30-50% к базовому сроку.
Этапы частично идут параллельно - пока тестируется один модуль, я уже начинаю интеграции для следующего, поэтому реальный срок для платформы среднего размера - 8-10 недель, а не сумма всех строк таблицы. После запуска обычно подключаю техническую поддержку сервиса, потому что любое обновление зависимостей или изменение API банка без нее превращается в разбор на скорую руку.
Из типичных ошибок, которые вижу на чужих проектах перед передачей мне на доработку - тестируют только счастливый путь без граничных случаев, забывают проверить платежный шлюз в боевом режиме до релиза и не нагружают систему заранее, поэтому первый же наплыв пользователей после рекламной кампании кладет базу данных.
Стоимость разработки платформы
Цена зависит от количества ролей, интеграций и того, нужен ли API для внешних партнеров. Больше всего на итоговую сумму влияют не дизайн и не количество экранов, а число внешних систем, с которыми должна разговаривать платформа, и глубина отчетности внутри. Ориентируюсь на такие цифры:
- веб-сервис, SaaS или SPA под ключ - от 300 000 ₽, срок от 8 недель;
- API или бэкенд отдельно на Laravel - от 100 000 ₽;
- CRM или админ-панель на React - от 100 000 ₽;
- дашборд и BI-отчеты на Vue.js - от 90 000 ₽;
- AI-интеграции - Claude API, RAG, чат-бот с базой знаний - от 50 000 ₽;
- автоматизация внутренних процессов в n8n - от 25 000 ₽;
- техническая поддержка после запуска - от 15 000 ₽ в месяц.
На рынке студии называют за аналогичный SaaS от 500 000 до 1 500 000 ₽ - в основном из-за штата менеджеров и фиксированных пакетов услуг. У фрилансеров и небольших команд цена обычно ниже за счет прямой работы с разработчиком без прослойки.
Частые вопросы
Сколько времени занимает разработка платформы для онлайн сервиса?
MVP с базовым сценарием и одной-двумя интеграциями собираю за 8-10 недель. Полноценная платформа с ролями, отчетами и несколькими интеграциями - от 3 месяцев, срок сильно зависит от того, сколько внешних систем нужно подключить.
Можно ли начать с MVP и дорастить до полноценной платформы?
Да, и это обычный путь - закладываю архитектуру с запасом на рост: разделяю модули, выношу настройки интеграций отдельно от бизнес-логики, чтобы добавление новой роли или платежной системы не требовало переписывать ядро.
Нужна ли отдельная мобильная разработка или хватит адаптивного веба?
Для старта обычно хватает адаптивной верстки или PWA - устанавливается на телефон, работает офлайн с частью функций и не требует прохождения модерации в сторах. Нативное приложение имеет смысл добавлять, когда есть подтвержденный спрос и нужны push-уведомления или доступ к камере и геолокации на уровне ОС.
Как масштабировать сервис при росте нагрузки?
Сначала разношу базу данных и приложение на разные серверы, добавляю кеш через Redis и очереди для тяжелых операций - отправка писем, генерация отчетов, обработка файлов. Если этого недостаточно, добавляю балансировщик и несколько инстансов приложения - архитектуру под это закладываю еще на этапе проектирования, а не когда сервер начинает падать под нагрузкой.