Back to blog
engineeringaiarchitecture

Building an AI CRM That Runs Locally on Your Machine

A deep dive into the architecture behind DenchClaw — why we chose to run an AI-powered CRM entirely on localhost, the technical decisions that made it possible, and what it means for performance and privacy.

Dench Team
Dench Team
·5 min read

Most CRM platforms run in the cloud. They store your customer data on someone else's servers, process your queries through someone else's infrastructure, and charge you monthly for the privilege. We built DenchClaw differently.

DenchClaw runs entirely on your machine. Your data never leaves your laptop. AI inference happens locally. And somehow, it's faster than the cloud alternatives.

This post explains how we built it and why.

Why Local-First?#

The decision to go local-first wasn't ideological — it was practical. After talking to hundreds of sales teams, three problems kept coming up:

  1. Latency kills workflows. When a rep is on a call and needs to pull up a contact, 200ms feels like an eternity. Local access is sub-millisecond.
  2. Data sensitivity is real. Enterprise deals involve NDAs, pricing strategies, and competitive intelligence. Many teams were uncomfortable with that data living on a third-party server.
  3. Offline access matters more than people think. Planes, trains, conference venues with bad WiFi — sales people work everywhere.
💡

Local-first doesn't mean local-only. DenchClaw syncs across devices when you're online, but every feature works without a connection.

The Architecture#

DenchClaw is a desktop application built on three layers:

The Data Layer#

We use SQLite with WAL mode as the primary database. Every CRM record — contacts, companies, deals, activities — lives in a single .db file on your machine.

CREATE TABLE contacts (
  id TEXT PRIMARY KEY,
  name TEXT NOT NULL,
  email TEXT,
  company_id TEXT REFERENCES companies(id),
  enrichment_data JSONB,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

SQLite was the right choice for several reasons:

  • Single-file database — easy to backup, sync, and reason about
  • WAL mode supports concurrent reads during writes
  • JSON support via JSONB for flexible enrichment data
  • Battle-tested at billions of deployments

The AI Layer#

The AI capabilities in DenchClaw use a hybrid approach:

FeatureModelRuns Where
Contact enrichmentGPT-4o-miniCloud API
Email draftingLocal LLMOn-device
Search & retrievalEmbedding modelOn-device
Lead scoringCustom classifierOn-device

For on-device inference, we use quantized models that fit comfortably in 8GB of RAM. The embedding model converts your CRM data into vectors stored in a local HNSW index, enabling semantic search across all your contacts and conversations.

async function enrichContact(contact: Contact): Promise<EnrichmentData> {
  const localEmbedding = await embedLocally(contact.name + " " + contact.email);
  const similarContacts = await vectorSearch(localEmbedding, { limit: 5 });
 
  // Only call cloud API if local data is insufficient
  if (similarContacts.length < 2) {
    return await cloudEnrich(contact);
  }
 
  return mergeEnrichments(similarContacts);
}
ℹ️

We're working on bringing the enrichment model fully on-device too. Early benchmarks show comparable quality to the cloud version with 4-bit quantization on Apple Silicon.

The Sync Layer#

When online, DenchClaw uses a CRDT-based sync protocol built on top of WebSockets. Each change generates an operation that can be applied in any order without conflicts:

type Operation =
  | { type: "INSERT"; table: string; id: string; data: Record<string, unknown> }
  | { type: "UPDATE"; table: string; id: string; field: string; value: unknown; hlc: string }
  | { type: "DELETE"; table: string; id: string; hlc: string };

The hlc (Hybrid Logical Clock) timestamp ensures causal ordering across devices. Two team members can edit the same contact simultaneously, and the merge is deterministic.

Performance Numbers#

We benchmarked DenchClaw against three popular cloud CRMs on common operations:

OperationDenchClaw (local)Cloud CRM ACloud CRM BCloud CRM C
Search 10k contacts3ms180ms240ms310ms
Open contact detail<1ms120ms200ms150ms
AI email draft800ms2.1s3.4sN/A
Full-text search8ms350ms500ms420ms

Local is just fundamentally faster. No serialization, no network round-trips, no cold starts.

What We Learned#

Building a local-first CRM taught us a few things:

  1. SQLite is criminally underrated for application databases. The "it's just for mobile" perception is wrong.
  2. CRDTs are hard but worth it. Getting conflict resolution right took us three iterations, but the result is a sync experience that feels magical.
  3. Quantized models are production-ready. The quality gap between cloud and local inference is narrowing fast, especially for domain-specific tasks.
  4. Desktop apps are back. The web-only era created a gap for fast, capable native software. Tools like Tauri and Electron (v30+) make building them practical.

What's Next#

We're working on a few exciting things:

  • Plugin system — Let teams extend DenchClaw with custom fields, automations, and integrations
  • On-device fine-tuning — Customize the AI models using your team's historical data, without sending it anywhere
  • Team analytics — Aggregated pipeline metrics that compute locally on each device and merge in real-time

If you're interested in trying DenchClaw, sign up for early access. We're onboarding teams every week.

Dench Team

Written by

Dench Team

The team behind Dench — AI-powered CRM and workflow automation.

DENCH

© 2026 DenchHQ · San Francisco, CA