How T24 Labs replaced three tools and a spreadsheet with a CRM built in 12 hours.
A production system of record for pipeline, bookings, outreach and email—with access boundaries enforced in the database, not hidden in the interface.
The studio was running on a patchwork
T24 Labs builds software and automation for clients, but its own commercial workflow was split across a lightweight CRM, a pipeline spreadsheet, booking emails and hand-tracked outreach. Every lead created another round of manual re-entry.
The problem became structural when a second operator needed access. A spreadsheet could not enforce who was allowed to see which leads. T24 needed a real system of record with role boundaries designed into the data layer.
Build the system of record
Built on Lovable with TanStack Start and Supabase, the CRM brought contacts, companies, opportunities, tasks, meetings and calendar activity into one application. Admin and operator roles are enforced through Postgres row-level security rather than interface logic.
Five hours to bring the automation home
In one focused session, the working CRM gained an approval queue for drafted outreach, model-routed research, scheduled jobs, a self-hosted email relay and full email threads inside the contact timeline. Core workflow logic moved from an external orchestrator into server code that ships with the application.
Every automated step degrades visibly: if enrichment or drafting fails, the record is still created and flagged for manual follow-up. Nothing disappears silently.
What runs in production now
T24 CRM now runs the studio's real pipeline with six webhook endpoints, sixteen database migrations and ten server-only automation modules. It captures bookings, prepares research briefs, records outreach, syncs email, merges duplicates, stores attachments and keeps an audit trail of inbound events.
Why it matters
The CRM is not a showcase prototype. It is the system T24 uses to run its business—and proof that a standard operational application can ship with real integrations, access control and failure handling at a pace that used to be reserved for throwaway demos.
Build time is derived from commit history using a 45-minute gap between sessions. Commit timestamps measure working sessions, not continuous typing, and may vary by roughly one hour under a different session threshold.