Scale — Running an Agency in One System: Projects, Money, CRM and Chat
Role
Full cycle: product and architecture, development, production rollout and ongoing work.
Tech
Stack. Go 1.25 (Echo v5, pgx) with React 19 on Vite — TanStack Router/Query, Tailwind, shadcn/ui, and Plate for rich text. PostgreSQL 17 with pgvector, Russian full-text search and forward-only goose migrations — 234 of them so far. Caddy with automatic Let's Encrypt in front.
Multi-tenancy at the database level. Separation between organizations rests on PostgreSQL Row-Level Security, not on a WHERE tenant_id = ? in application code. Forgetting the filter in a new query is physically impossible.
Two-layer permissions. The first layer is a route-level permission matrix per role: may this role call this class of endpoint at all? The second is a resource policy inside the service: may this user reach this project, task, chat, page, file or call? A denial at the second layer after the first allowed the request is expected behaviour, not a bug.
A job queue without Redis. Background work — Telegram and email delivery, AI and search, calls, automations, recurring tasks, load and analytics recomputation, periodic cleanup — runs on River over Postgres. Realtime is an in-process WebSocket hub. Redis arrives when more than one app instance is needed, not before.
Verification. Around a thousand Go tests, over three hundred frontend tests, and a separate e2e layer.
Key features
- 01Projects and tasks in full
- 02Telegram as part of the system
- 03Project money next to the tasks
- 04CRM with several pipelines
- 05The client inside the system
Problem
A digital agency almost never lives in one system. Tasks in a tracker, client conversation in Telegram, files in cloud storage, money in a spreadsheet, leads in a separate CRM, the knowledge base in a third service. Every link between them rests on one person who remembers where things are.
Three gaps cost the most. The first is between conversation and tasks: a decision is made in a chat, nobody creates the task, and a week later nobody remembers. The second is between the project and its money: the manager sees deadlines, the accountant sees margin, and they meet at the end of the quarter. The third is between the team and the client: someone assembles a status report by hand, because letting the client inside the system feels risky.
Existing trackers cover the first layer and stop there: Telegram is a notification channel to them, not a source of work; there are no finances at all; and an "external user" means either everything or nothing.
Audience
| Role | Use case |
|---|---|
| Agency owner | Sees every project, the team's load and the money in one place, without pivot tables |
| Project manager | Runs a project from brief to delivery: tasks, deadlines, materials, finances and conversation side by side |
| Team member | Receives tasks straight from the working chat instead of switching between five services |
| Sales | Works in a CRM with several pipelines and the correspondence inside the deal card |
| Agency's client | Enters the project with limited rights and sees the status themselves, without an emailed report |
| Department head | Watches their own department's load and distributes work across people |
What's different
Compared to a tracker with Telegram notifications: Here Telegram is a source of work, not a delivery channel. The bot mirrors working chats into the project: a message can become a task, be saved as an artifact, have its media imported into materials, or be pinned. Search runs over the Russian text of the conversation.
Compared to a tracker without money: Finances live inside the project next to the tasks: planned volume, invoices, income and expenses, receivables and payables, cash flow forecast. The system points out the gaps itself — for example, that income is planned while the planned volume is missing, so there is nothing to compare the actuals against.
Compared to "let's give the client guest access": The external role isn't a stripped-down employee. A project has a visibility mode, with per-resource grants and denials on top of it that can expire, and sensitive areas — email, automations, analytics, settings, chats — are never opened by broad project visibility.
Compared to a tracker plus a separate CRM: The deal and the project live in one system: the deal links to the project, and the project's finances show which deal they came from. There can be several pipelines, not one per company.
Compared to analytics you have to assemble: Load, attention and the timeline are computed as background jobs and are available company-wide immediately. The AI assistant answers from that same data rather than from general knowledge about the world.
Screenshots
Customization
- 01Client visibility — a project-level mode plus per-resource grants and denials that can expire.
- 02CRM pipelines — as many pipelines and stages as needed, with custom reports and forecasting.
- 03Automations — rules that move tasks through the process without a human.
- 04Custom fields — for the agency's own entities and processes.
- 05Notifications — per channel (in-app and Telegram) and grouped into a digest.
- 06Org structure — departments, heads and their link to projects.
Other projects
Need something like this?
Tell me about the task — I'll suggest an approach, pick a stack and scope it out.