Inside Coldfire CRM: the architecture behind an AI cold-calling platform

The problem worth building for

Sales reps hate admin. After a call they should be thinking about the next one — not typing notes, updating pipeline stages, or scheduling follow-ups. That loop kills momentum, and it's the single biggest reason outbound teams under-perform.

Coldfire CRM was built to end that loop. A browser-based VoIP stack calls the lead, an AI model transcribes and summarises the conversation in real time, and an outcome-aware workflow engine fires the right follow-up automatically — move the deal to negotiation, send the pricing email, book the demo on the rep's calendar. No keystrokes.

This post is about what's underneath: the architecture decisions that make that feel instant, and the ones that keep it boring at scale. If you're evaluating whether to build a custom CRM — for yourself or with us — this is the honest picture of what one takes.

The one rule: nothing slow touches the live call

The defining constraint of a calling CRM is latency. A rep is mid-conversation; anything that adds friction to that moment loses.

So the system is split along a single line:

In the call path, in-process and fast: audio, live transcription, the script panel, and call-state changes. Transcription lands sub-second — fast enough to surface mid-call, not as a post-mortem.
Everything else, on a queue: outbound emails, CRM syncs, analytics events, exports, digest notifications. All of it rides a queue with retries.

That split is why P99 latency stays flat as call volume scales. One flaky upstream — an email provider having a bad day, a webhook receiver timing out — never blocks a rep. It just retries in the background.

If you take one thing from this post, take the question behind that rule: for each feature, does it need to happen during the moment, or just because of it? Most systems put far too much in the first bucket.

The data layer: Postgres, treated with respect

Coldfire's relational core is Postgres — not because it's fashionable, but because pipeline data is relational to its bones: leads, calls, outcomes, deals, teams, permissions.

The unglamorous work that made it fast:

Indexes tuned against real traffic, not against the queries that look clean on paper. Query plans get reviewed with production-shaped data.
Versioned migrations from day one, so the schema can evolve while the system runs.
A hardened Strapi core drives the content and configuration APIs — the parts of the system where an admin UI for free beats hand-rolling CRUD.

Auth: written once, reused everywhere

CRMs die by permission sprawl: managers see team dashboards, reps see their pipeline, admins see billing — and every new feature adds another place to get access control wrong.

Coldfire has one identity layer, one session primitive, and every route goes through the same guard. The auth boundary was written once, early, and reused everywhere since. That single decision is the difference between "add a role in an afternoon" and "audit forty endpoints and hope."

We build this pattern into everything now — the client portal we shipped for Minrenovering runs the same way, with role-based access for homeowners, crew leads, and admins, plus an audit log of every meaningful change.

The workflow engine: outcomes, not buttons

The feature that makes Coldfire feel like magic is the least magical part of the stack: a workflow engine keyed on call outcomes.

When the AI classifies a call — interested, callback requested, wrong person, not now — that outcome is just an event. Workflows subscribe to events: "on interested, send the pricing email, move the deal, and book a follow-up slot." Reps configure automations in plain language; the engine is an event bus with good ergonomics.

The lesson generalises: don't build "AI features." Build a clean event model, then let the AI be one producer of events among many. When the models improve, you swap a producer — not your product.

Shipping it: Docker, Kubernetes, and deliberate boredom

Services are packaged into Docker images and rolled out to a Kubernetes cluster with autoscaling, rolling updates, feature flags, and zero-downtime releases. Observability, secrets management, and CI/CD are wired in from day one — so the platform stays boringly reliable while the surface keeps shipping fast.

Integrations — Twilio for telephony, HubSpot, Slack, Google Calendar — are wired directly, behind the same queue-and-retry machinery as everything else. No middleware glue holding revenue together.

What we'd tell you before you build one

Custom is worth it when the process is the product. Coldfire exists because no off-the-shelf CRM treats the call as the atomic unit. If your edge is a process HubSpot can't model, that's the signal.
Budget for the boring 40%. Auth, migrations, queues, observability — the parts nobody demos are the parts that decide whether the system survives success.
Ship a working demo every week. Coldfire ran on weekly demos from week one, like every project we take. A CRM that first appears at month four is a rewrite waiting to happen.

Thinking about a system like this for your own team? Start with the custom CRM page — the FAQ covers cost and timelines honestly — or just book a 30-minute call and we'll tell you whether custom is even the right move for you.