Scale — система управления агентством: проекты, деньги, CRM и переписка в одном месте
Роль
Полный цикл: продукт и архитектура, разработка, вывод в прод и развитие.
Технологии
Стек. Go 1.25 (Echo v5, pgx) и React 19 на Vite с TanStack Router/Query, Tailwind и shadcn/ui, rich-text на Plate. PostgreSQL 17 с pgvector, полнотекстовым поиском по русскому и forward-only миграциями goose — их уже 234. Caddy с автоматическим Let's Encrypt перед приложением.
Мультитенантность на уровне базы. Разделение данных между организациями держится на Row-Level Security в PostgreSQL, а не на условии WHERE tenant_id = ? в коде приложения. Забыть фильтр в новом запросе физически нельзя.
Двухслойные права. Первый слой — матрица разрешений по ролям на уровне маршрута: может ли роль вообще вызвать такой эндпоинт. Второй — политика на конкретный ресурс внутри сервиса: имеет ли этот пользователь доступ к этому проекту, задаче, чату, странице, файлу или звонку. Отказ на втором слое после разрешения на первом — штатное поведение, а не баг.
Очередь задач без Redis. Фоновая работа — доставка в Telegram и почту, AI и поиск, звонки, автоматизации, повторяющиеся задачи, пересчёт загрузки и аналитики, периодическая уборка — крутится на River поверх Postgres. Реалтайм — WebSocket-хаб в процессе. Redis появится, когда понадобится больше одного инстанса, а не заранее.
Проверки. Около тысячи Go-тестов, свыше трёхсот тестов фронтенда и отдельный слой e2e.
Ключевые фичи
- 01Проекты и задачи целиком
- 02Telegram как часть системы
- 03Деньги проекта рядом с задачами
- 04CRM с несколькими воронками
- 05Клиент внутри системы, а не рядом
Проблема
Digital-агентство почти никогда не живёт в одной системе. Задачи в таск-трекере, переписка с клиентом в Telegram, файлы в облаке, деньги в таблице, лиды в отдельной CRM, база знаний в третьем сервисе. Каждая связка держится на человеке, который помнит, где что лежит.
Дороже всего обходятся три разрыва. Первый — между перепиской и задачами: в чате приняли решение, задачу никто не завёл, через неделю никто не помнит. Второй — между проектом и деньгами: сроки видит менеджер, маржу — бухгалтер, и встречаются они в конце квартала. Третий — между командой и клиентом: чтобы показать заказчику статус, кто-то вручную собирает отчёт, потому что пускать клиента внутрь системы страшно.
Существующие трекеры закрывают первый слой и упираются в остальные: Telegram у них — канал уведомлений, а не источник работы; финансов нет вообще; «внешний пользователь» означает либо всё, либо ничего.
Для кого
| Роль | Сценарий использования |
|---|---|
| Руководитель агентства | Видит все проекты, загрузку команды и деньги в одном месте, без сводных таблиц |
| Проектный менеджер | Ведёт проект от брифа до сдачи: задачи, сроки, материалы, финансы и переписка рядом |
| Исполнитель | Получает задачи из рабочего чата и не переключается между пятью сервисами |
| Продажи | Работают в CRM с несколькими воронками и перепиской внутри карточки сделки |
| Клиент агентства | Заходит в проект с урезанными правами и видит статус сам, без отчёта по почте |
| Руководитель отдела | Смотрит загрузку своего отдела и распределяет работу по людям |
Чем отличается
От таск-трекера с уведомлениями в Telegram: Здесь Telegram — источник работы, а не канал доставки. Бот зеркалит переписку рабочих чатов в проект: сообщение можно превратить в задачу, сохранить как артефакт, импортировать медиа в материалы или закрепить. Поиск идёт по русскому тексту переписки.
От трекера без денег: Финансы лежат в проекте рядом с задачами: плановый объём, счета, доходы и расходы, дебиторка и кредиторка, прогноз денежного потока. Система сама подсказывает разрывы — например, что доходы запланированы, а планового объёма нет, и факт не с чем сравнить.
От «дадим клиенту гостевой доступ»: Внешняя роль — не урезанный сотрудник. У проекта есть режим видимости, поверх него точечные разрешения и запреты с истечением срока, а чувствительные разделы — почта, автоматизации, аналитика, настройки, чаты — не открываются широкой видимостью проекта.
От связки «трекер + отдельная CRM»: Сделка и проект живут в одной системе: из сделки видно проект, в финансах проекта видно, из какой она сделки. Воронок может быть несколько, а не одна на компанию.
От аналитики, которую надо собирать: Загрузка, внимание и таймлайн считаются фоновыми задачами и доступны сразу по компании. ИИ-ассистент отвечает по этим же данным, а не по общим знаниям о мире.
Скриншоты
Кастомизация
- 01Видимость для клиента — режим на уровне проекта плюс точечные разрешения и запреты с истечением срока.
- 02Воронки CRM — своё количество воронок и стадий, свои отчёты и прогноз.
- 03Автоматизации — правила, которые двигают задачи по процессу без участия человека.
- 04Кастомные поля — под свои сущности и процессы агентства.
- 05Уведомления — по каналам (в приложении и Telegram) и с группировкой в дайджест.
- 06Оргструктура — отделы, руководители и привязка к проектам.
Другие проекты
Нужно что-то подобное?
Расскажите о задаче — предложу подход, подберу стек и оценю сроки.