The internal system of a small software studio, built to replace a spreadsheet, a calendar and memory with a single place. It is live at crm.somoskyber.com.br and used every day in real operations.
A small studio's operation fits in a spreadsheet until it stops fitting. The proposal in one file, the invoice in another, whatever was agreed with each client living in the memory of whoever took the call, and the next step of each deal nowhere at all. The cost does not show up at once: it shows up as a forgotten invoice, a follow-up that never went out, and a client question nobody can answer without digging.
The goal was not to have a CRM. It was to have one place where sales, delivery, finance and support look at the same data, under the same rules about who can see what, and where the day's work is already assembled before anyone asks what to do next.
One Next.js application serves four very different things over the same data model and the same authorization layer.
The interesting part is not how many surfaces there are, it is that all four share the same business rules and the same per-user isolation instead of each reimplementing its own version. A rule fixed once holds for the dashboard, the agent, the public page and the cron job at the same time.
All 70 tools run under one endpoint, and who is operating is resolved from the request token. Identity is propagated through AsyncLocalStorage so it cannot leak between concurrent requests. Each partner operates only their own data, under the same rules as the dashboard.
133 RLS policies across 29 tables, with SECURITY DEFINER functions for the composite decisions: who can see which lead, who is an admin. The front end is never the security boundary. Even holding the public key, Postgres refuses.
A sequence of four touches with distinct angles and growing intervals. Prioritisation uses signals from the lead: public rating, review volume, digital presence and historical niche. There is a daily cap per person and a global opt-out list. A reply from the lead pauses the automation and hands the case back to a human.
Four specific uses: draft the opening approach, draft a proposal from the catalogue, write a follow-up by reading the conversation history, and produce the daily read of the numbers. Each with explicit rules against inventing a price, a deadline or a deliverable, plus a review layer that re-reads the generated text and flags claims the system state does not support.
Lead sharing between partners, a percentage per lead and payout calculation, with finance respecting the split. Per-user isolation and revenue split are the same problem seen from two sides.
The system never sends a message automatically, on any channel, and that is deliberate. It builds the queue, writes the text and records the send, but the send click is always human.
The reason is operational and legal risk. The official API requires documented consent the base does not have. The unofficial alternatives violate the terms and get the account banned. And the number used for prospecting is the same one that serves the clients who already pay.
Automating the send would save minutes and put the main channel of the business at risk. The trade does not pay. The system is designed around that choice, not in spite of it.
Of the 21 routes, 17 are protected and 4 are public by token. Ten production dependencies in total: no Tailwind and no component library, styling is inline over CSS variables, with a light and a dark theme.
Want to see the rest of the work, or talk about a project?
Updated 5 August 2026