Your CRM Should Run on Your Laptop

Here's something that surprised me. The fastest CRM I've ever used runs on my laptop. Not on some beefy server in us-east-1, not in a container orchestrated by Kubernetes, not behind a CDN. Just a process on localhost, reading and writing to files on my own filesystem.

It shouldn't be surprising, really. Of course software running on the machine right in front of you is faster than software running on a computer thousands of miles away. And yet almost everyone building CRM software today starts with the assumption that it has to live in the cloud. That assumption is so deeply embedded in how we think about this category that questioning it feels almost naive. Cloud is just where CRM lives. Salesforce proved that two decades ago. Case closed.

Except I don't think the case is closed at all. I think we're at the beginning of a pretty significant shift in how software like this gets built, and the CRM that runs on your laptop is just one early symptom of it.

I've been building DenchClaw — a local-first, AI-native CRM — for the past year, and the experience has changed how I think about a lot of things. Not just about CRM, but about the architecture of software generally, about what the cloud is actually for versus what we've been using it for out of habit, and about what happens when you take AI seriously as the primary interface to an application rather than bolting it on as a feature.

Let me start from the beginning.

When I first started talking to sales teams about their tools, the thing that struck me wasn't the complaints about any particular product. It was the resignation. People had just accepted that their CRM was going to be slow. That searching for a contact was going to take a couple hundred milliseconds at best. That opening a deal record was going to involve a loading spinner. That the whole experience of using the tool that's supposed to help them sell was going to feel like wading through mud.

I remember sitting with a sales rep at a startup in San Francisco — maybe fifteen people, Series A, the kind of company where everyone is scrappy and moves fast — and watching her work. She was on a call with a prospect, and she needed to pull up the prospect's company info. She clicked into her CRM, and there was this moment. Maybe 300 milliseconds. Maybe half a second. It's hard to say exactly. But there was a visible pause while the page loaded. She filled the silence on the call with a little "uh, let me just pull that up." By the time the data appeared, the moment had passed. The conversational rhythm was broken.

Three hundred milliseconds. That's nothing, right? That's faster than a human blink. And yet it was enough to interrupt her flow. Enough to make the tool feel like friction rather than an extension of her thinking.

When I got back to my apartment that night, I opened a terminal and ran a query against a local DuckDB database with ten thousand rows. The result came back in under three milliseconds. Not because DuckDB is magic — although it is remarkably good — but because the data was right there. On the same machine. No network hop, no serialization, no TLS handshake, no load balancer, no application server parsing a request, no ORM translating a query, no connection pool, no result serialization, no network hop back. Just a process asking the kernel for some bytes that are already in memory or on a disk that's literally inches away from the CPU.

It seems to me that we've been so focused on the benefits of cloud architecture — and there are real benefits, which I'll get to — that we've forgotten how fast computers actually are when you let them do local work. A modern MacBook has more computing power than the servers that ran most of the internet fifteen years ago. And we're using it to... render a loading spinner while we wait for a response from a server in Virginia?

Something about that picture felt wrong.

The Pendulum#

The history of computing is basically a pendulum swinging between centralized and distributed. Mainframes were centralized. PCs distributed the computing to the edge. Then the web centralized it again into servers. Then mobile put powerful computers in everyone's pocket, but we mostly used them as thin clients to cloud services, so it was kind of centralized again.

I think we're at another inflection point. The machines on people's desks and in their bags are extraordinarily powerful — Apple Silicon alone has changed what's possible on a laptop in ways that I don't think the industry has fully absorbed yet. An M-series Mac can run a quantized language model, maintain a vector search index, and serve a web application all simultaneously without breaking a sweat. That wasn't true even three years ago.

And at the same time, the cloud has gotten expensive. Not just in dollar terms, though there's that too. Expensive in complexity. Expensive in latency. Expensive in the cognitive overhead of managing infrastructure. Expensive in the privacy implications of storing everyone's data in a shared multi-tenant system.

When Marc Benioff started Salesforce in 1999, the pitch was genuinely revolutionary. "No software" — meaning no installation, no servers to manage, no IT department needed. Just open a browser and go. And for that era, with those constraints, it was absolutely the right call. Installing and maintaining enterprise software in 1999 was a nightmare. The cloud abstracted all of that away, and it was a massive improvement.

But the constraints have changed. Installing software in 2026 is trivial. You run a single command in your terminal and the thing is up and running in seconds. The complexity that the cloud was originally abstracting away has largely been solved at the tooling level. Package managers, container runtimes, auto-updaters — we have good solutions for all the problems that made "no software" such a compelling pitch in 1999.

So what are you actually getting from the cloud in 2026? For some applications, a lot. If you're running a social network, you need a centralized server because the whole point is that everyone's data is in the same place. If you're running a payment processor, you need centralized infrastructure for transaction consistency. If you're running a search engine, you need massive distributed systems to crawl and index the web.

But a CRM? A CRM is fundamentally a personal or team database. It's your contacts, your deals, your pipeline, your notes. It's your data. The fact that it lives on someone else's server isn't a feature — it's a historical accident. A side effect of the fact that when CRM went to the cloud, there was no good alternative. Now there is.

Why Local Isn't a Constraint#

I think the deepest mistake in how people think about local-first software is treating it as a constraint. As if running locally is a limitation you have to work around, rather than a fundamentally better starting point for certain kinds of applications.

When your CRM runs locally, you get properties that are impossible to achieve in the cloud, not just difficult — actually impossible, as in the laws of physics won't let you.

The speed of light is roughly one millisecond per 186 miles. If your server is in Northern Virginia and you're in San Francisco, that's about 2,400 miles, so your absolute minimum round-trip time is around 25 milliseconds. In practice, with all the routing and processing, you're looking at 50 to 200 milliseconds for a typical API call. And that's the good case — that's assuming fast internet, no packet loss, no server-side queuing.

When your data is on localhost, the round-trip time is essentially zero. The latency is bounded by disk I/O and computation, which on modern hardware is measured in microseconds, not milliseconds. The difference isn't incremental. It's categorical. It's the difference between "instant" and "fast." And that gap matters enormously for interactive software that people use all day.

There's a concept in user interface design called the Doherty Threshold, named after a study IBM published in 1982. The finding was that when computer response time drops below 400 milliseconds, both the computer and the user become more productive. Not just the user — the whole system. People change how they work when the tool is fast enough. They try more things. They explore more. They don't batch up their queries or plan their clicks to minimize waiting. They just flow.

Most cloud CRMs are right at or above the Doherty Threshold for many operations. Local CRMs are so far below it that the threshold becomes irrelevant. The tool becomes invisible in the best sense — it stops being a thing you interact with and starts being a thing you think through.

Then there's the privacy angle, which I initially thought was going to be our main selling point but turned out to be more nuanced than I expected. The sales teams we talked to did care about privacy, but not in the abstract way that privacy advocates talk about it. They cared about it in very specific, practical terms.

A VP of Sales at a mid-market SaaS company told me something that stuck with me. She said, "I don't care about privacy in general. I care about the fact that our pricing strategy for enterprise deals is in our CRM, and I'm trusting a vendor I've never met to not look at it, not get breached, and not train a model on it." That's not a philosophical privacy concern. That's a business risk concern. And it's completely legitimate.

When your CRM runs locally, there's no trust question. Your data is in a file on your disk, encrypted with your machine's encryption. No vendor can see it because no vendor has it. No breach of a cloud provider's infrastructure can expose it because it was never on that infrastructure. The attack surface isn't smaller — it's categorically different.

The third thing, which I actually think is the most underrated, is offline access. Not because people are offline that often — although sales people in particular are offline more than most knowledge workers, because they travel constantly — but because offline capability is a forcing function for good architecture. When you commit to offline-first, you can't cheat. You can't rely on a server to be the source of truth. You can't make network calls as part of your critical path. You have to build the application in a way that everything important works without a connection, and then sync is an optimization that happens when connectivity is available.

This constraint leads to better software. It's similar to how building for mobile used to force web developers to think about performance and simplicity in ways they wouldn't have if they were only targeting desktops. The constraint was annoying, but the software that emerged from it was better for everyone, including desktop users.

Let me talk about the technical decisions, because I think they're interesting and they illustrate a broader point about how the choice of local-first cascades through your entire architecture.

The first big decision was the database. If you'd asked me a few years ago what database to use for a local-first application, I probably would have said SQLite without hesitation. SQLite is phenomenal — it's probably the most deployed piece of software in human history, it's rock solid, and it's designed specifically for embedded use. We actually started with SQLite.

But then we switched to DuckDB, and the difference was dramatic.

DuckDB is a relatively young database — it came out of CWI Amsterdam, the same research lab that produced MonetDB. It's an in-process analytical database, which means it's designed for the kind of queries that CRM data actually demands. When a sales manager wants to see their pipeline broken down by stage, by rep, by quarter — that's an analytical query. When you want to search across ten thousand contacts with fuzzy matching and sorting and aggregation — that's an analytical query. SQLite can do these things, but DuckDB was built for them.

The performance difference for analytical workloads was often 10x to 100x. Queries that took 50 milliseconds in SQLite took 2 milliseconds in DuckDB. And this matters because it determines what kinds of features you can build. When aggregation queries are cheap, you can show real-time pipeline analytics without precomputation. When full-table scans are fast, you can implement search without maintaining a separate search index. When PIVOT operations are native, you can reshape data on the fly without ETL pipelines.

There's a deeper point here too. DuckDB stores data in a columnar format, which means it reads only the columns it needs for a given query rather than reading entire rows. For a CRM where records might have dozens of fields but a typical view only shows five or six, this is a massive efficiency gain. It's the same insight that drove the big data revolution in cloud analytics — columnar storage is just better for analytical workloads — but now it's running on your laptop, on a single file, with zero configuration.

We also made an unusual choice for our data model. Most CRMs use a rigid relational schema — contacts table, companies table, deals table, each with fixed columns. We use an Entity-Attribute-Value model with materialized PIVOT views. The EAV pattern gets a bad reputation, and honestly in most contexts it deserves it. EAV on a traditional row-store database is slow and awkward to query. But EAV on DuckDB with its native PIVOT support turns out to be surprisingly elegant.

What this means in practice is that every record in DenchClaw is just a bag of key-value pairs. A contact isn't a row in a contacts table with fixed columns — it's an entity with a set of attributes that can vary per record, per workspace, per user. If you want to add a "LinkedIn URL" field, you just add it. If you want a custom "Deal confidence" score, you just add it. There's no schema migration, no column limit, no admin panel for custom fields. The schema is emergent from the data itself.

And then the PIVOT views materialize this flexible data into something that looks and queries like a regular table. So you get the flexibility of a document store with the queryability of a relational database. DuckDB makes this work because its columnar engine handles the pivot operation efficiently, and because its query optimizer is smart enough to push predicates down through the pivot.

Everything is just files. The database is a file. Your configuration is a file. The skills that define what the AI agent can do are files. Your sync state is a file. When you back up DenchClaw, you copy a directory. When you want to inspect what's in your CRM, you can open the database file with any DuckDB client. There's no proprietary binary format, no opaque data store, no "export" button that gives you a lossy CSV. It's your data, in an open format, on your filesystem.

This is something I feel strongly about and I think the industry has gotten badly wrong. Your data should be in formats you can read, in locations you control, using tools that don't lock you in. That's not a radical position. It's how computing used to work before everything moved to the cloud and we somehow accepted that it was normal for a company to hold your data hostage behind an API.

Agent-Native, Not AI-Assisted#

The most interesting part of DenchClaw's architecture, and the part I think has the most implications for the future of software generally, is how we think about AI.

Most software companies right now are "adding AI" to their products. You know what this looks like. There's an existing application with buttons and forms and tables, and then someone adds a chat widget in the corner or an "AI-powered" autocomplete or a "smart" suggestion feature. The AI is an accessory. It's bolted onto the side of the thing, a feature among features.

I think this is exactly backwards, and it's going to look as quaint in five years as a "social media strategy" that consists of putting a Facebook Like button on your homepage.

DenchClaw is agent-native. The AI isn't a feature of the CRM — the AI is the primary operator of the CRM. The human doesn't click buttons and fill out forms and then occasionally ask the AI for help. The human tells the agent what they want, and the agent operates the CRM to make it happen.

This is a subtle but profound difference. In a traditional CRM, the user interface is a set of CRUD forms. The user's job is to be a data entry clerk — to look at information and transcribe it into the right fields, to update records when things change, to run reports by specifying parameters. The AI can help with this, sure, but it's helping with a task that arguably shouldn't exist in the first place.

In an agent-native CRM, the user interface is a conversation. You say "log my call with Sarah at Acme, we talked about their Q3 budget, she's interested but needs VP approval." The agent parses this, creates or updates the relevant contact and company records, logs the activity, updates the deal stage, maybe drafts a follow-up email. The user didn't fill out a single form. They just described what happened, like they'd tell a colleague over coffee.

The thing that makes this work technically is something we call the skills architecture. Instead of hardcoding what the agent can do, we define capabilities in markdown files — SKILL.md files that describe, in plain English and structured metadata, what a skill does, what inputs it needs, and what operations it performs. The agent reads these skill files to understand its capabilities, and it composes them to handle complex requests.

This is directly inspired by how tools like Cursor and Codex handle context — giving the AI a filesystem of knowledge to draw from rather than a fixed set of function signatures. And it has the same benefit: the system is infinitely extensible without code changes. If you want DenchClaw to integrate with a new tool, you write a SKILL.md file that describes the integration. If you want it to handle a new kind of workflow, you write a skill for it. The agent becomes more capable as you add files to a directory.

I think this is the right architecture for AI-native software in general. The skill file is the new API endpoint. Instead of defining capabilities as REST routes with JSON schemas, you define them as markdown files with natural language descriptions. The consumer of the API isn't another program — it's an AI agent that can read, understand, and compose these capabilities dynamically.

There's a historical analogy I keep coming back to. When React came out in 2013, it changed how people thought about building UIs. Instead of imperatively manipulating the DOM, you declared what the UI should look like and let the framework figure out the updates. It was a fundamental shift in abstraction level. OpenClaw — the open-source framework DenchClaw is built on — feels to me like early React. It's a new primitive for building AI-native applications. And DenchClaw is trying to be what Next.js was to React: an opinionated, batteries-included product that shows what the primitive can do when you build a complete experience around it.

That might sound grandiose. Maybe it is. But the pattern feels right to me. React gave you components. Next.js gave you a framework for building apps out of components. OpenClaw gives you an agent runtime with skills. DenchClaw gives you a complete CRM built out of that runtime. The layers map well.

The Hard Part: Sync#

One thing I didn't expect when we started building DenchClaw was how much time we'd spend on sync. If you're building a local-first application, sync is the hard problem. Everything else — the local database, the UI, the AI layer — is honestly pretty straightforward. You're just building software the way people used to build software before everything had to go through a server. But sync, collaboration, the ability for multiple people on a team to work with the same data — that's where local-first gets genuinely difficult.

The fundamental challenge is conflict resolution. If two people edit the same contact at the same time, who wins? In a cloud CRM, the answer is simple: the server is the source of truth, last write wins, and maybe you show a warning if someone else changed the record while you were editing it. In a local-first CRM, there is no server to be the arbiter. Each device has its own copy of the data, and changes can happen offline, and you need to merge them deterministically when the devices reconnect.

We use CRDTs — Conflict-free Replicated Data Types — for this. CRDTs are a family of data structures that have a mathematical property: any two replicas that have seen the same set of operations will converge to the same state, regardless of the order in which they received those operations. This means you don't need a central server to resolve conflicts. The merge is determined by the data structure itself.

The specific kind of CRDT we use is based on Hybrid Logical Clocks. Each operation gets a timestamp that combines a physical clock reading with a logical counter, which gives you causal ordering — if operation A caused operation B, then A's timestamp is guaranteed to be earlier than B's — without requiring synchronized clocks. This is important because you can't rely on wall clock time when devices might be offline and their clocks might drift.

Getting CRDTs right took us three full iterations. The first version was too naive — we used simple last-writer-wins registers for everything, which meant that if two people edited different fields of the same contact simultaneously, one person's changes could be lost. The second version was too complex — we tried to implement a full state-based CRDT with merge functions for every field type, and the codebase became impossible to reason about. The third version, which is what we ship today, uses operation-based CRDTs at the field level with a Hybrid Logical Clock for ordering. It's the right balance of correctness and simplicity.

The sync protocol itself is built on WebSockets. When a device comes online, it sends its vector clock — a compact representation of which operations it has seen — to the sync server. The server responds with all the operations the device is missing. The device applies them locally, and its state converges with everyone else's. The sync server doesn't interpret the operations or resolve conflicts. It's just a relay. The intelligence is in the CRDT logic on each device.

This is philosophically important. The sync server is a convenience, not a dependency. If it goes down, nothing breaks. Every device has a complete copy of the data and can operate independently for as long as it needs to. When the server comes back, everything catches up automatically. This is a fundamentally different reliability model from cloud software, where a server outage means the application is down for everyone.

I think the CRDT approach is going to become much more common in the next few years. Not just for CRM, but for many kinds of collaborative software. The tools have gotten dramatically better — libraries like Yjs and Automerge have made it accessible to application developers who don't want to implement the theory from scratch. And the user experience of CRDT-based sync is genuinely better than the cloud model for many use cases. Changes appear instantly on the local device, and then propagate to other devices in the background. There's no spinner, no "saving..." indicator, no optimistic UI that might roll back. Your changes are always immediately real.

One of the more surprising aspects of building DenchClaw has been the browser automation layer. When I describe this to people, they often look at me like I'm slightly crazy, but hear me out.

DenchClaw can automate your Chrome browser. Not a sandboxed browser instance, not a headless browser in a container somewhere — your actual Chrome browser, with your actual profile, your cookies, your logged-in sessions. The agent can navigate to LinkedIn, pull up a prospect's profile, grab the relevant information, and populate your CRM record with it. It can open your email client and compose a message. It can check a prospect's website for recent press releases or blog posts.

The reason this works is that the agent is running on your machine. It has the same access you do. It's not a cloud service trying to scrape websites through a proxy — it's a local process controlling a local browser. This means it can access anything you can access, with your credentials, through your normal browser session.

I know this sounds concerning from a security perspective, and it should give you pause. We've thought about it a lot. The key insight is that the trust model is fundamentally different from a cloud agent. A cloud agent that has your browser credentials is a security nightmare — you're giving a third party access to all your online accounts. A local agent that controls your browser is more like an extremely fast and tireless version of you. It has the same access you do, because it's running as you, on your machine. If you trust yourself to log into LinkedIn, you can trust the local agent to do the same thing.

This is another case where local-first isn't just a privacy feature — it enables capabilities that would be reckless or impossible in a cloud architecture.

Let me zoom out and talk about what I think all of this means for the future of software.

It seems to me that we're at the start of a larger unbundling of the cloud. Not an abandonment of the cloud — cloud computing isn't going away, and it remains the right architecture for many things. But a recognition that the cloud became the default for too many things, and that some of those things work better locally.

The cloud originally won for three reasons: zero installation, automatic updates, and collaboration. In 2026, those advantages have eroded significantly. Installation is trivial — you run a single command. Updates can be automatic for local software too; most desktop apps auto-update seamlessly. And collaboration, the last remaining moat, is being solved by CRDTs and sync protocols that work just as well for local-first apps as centralized servers do for cloud apps.

Meanwhile, the advantages of local have only grown. Hardware has gotten dramatically more powerful. Apple Silicon put genuinely impressive compute on every Mac. AI models can now run locally at usable quality. Analytical databases like DuckDB can handle workloads that used to require a data warehouse. The tools for building desktop applications — Tauri, Electron, native frameworks — have matured enormously.

And there's a new advantage that didn't exist before: AI benefits enormously from locality. When the AI agent has direct filesystem access, when it can read your data without an API roundtrip, when it can maintain context in memory without serializing and deserializing state through HTTP, it's faster and more capable. The local machine is the natural home for an AI agent that's working on your behalf, just as it was the natural home for programs that worked on your behalf before the cloud era.

I sometimes think about what would happen if you invented CRM today, with no prior assumptions. No legacy of Salesforce, no expectation that business software has to be SaaS. You'd look at the requirements — store contact information, track deals through a pipeline, log activities, analyze performance — and you'd think, "this is a database with a nice UI on top." You would not, I think, conclude that the correct architecture involves sending all this data to a remote server. You'd store it locally, make it fast, and add sync for collaboration. Which is exactly what DenchClaw does.

The fact that we're building this at a time when the CRM industry generates over $70 billion in annual revenue — almost all of it from cloud products — might seem like a mistake. Why would anyone leave Salesforce or HubSpot for a local application? The answer is the same as why anyone left Subversion for Git, or why anyone left PHP for Rails, or why anyone left on-premise Exchange for Gmail. Not because the incumbent was bad, but because the new thing enabled a fundamentally better workflow.

Git didn't just move Subversion to a new server. It changed how people collaborated on code by making every clone a full repository. Local-first CRM doesn't just move Salesforce to your laptop. It changes how people interact with their customer data by making every instance a complete, intelligent system that works instantly and never goes down.

Why MIT#

I want to say something about the open source decision, because I think it's misunderstood.

DenchClaw is MIT licensed. All of it. The client, the agent runtime, the skills framework, everything. When people hear this, they often ask some version of "but how will you make money?" or "aren't you afraid someone will just copy it?"

The honest answer to the second question is: no, not really. Here's why.

If you're building something genuinely new — not just a clone of an existing product with a slightly different UI, but something architecturally different — then open source is the fastest way to win. You're not competing on features that can be copied. You're competing on architecture and ecosystem. And architecture and ecosystem compound. Every person who builds a skill for DenchClaw makes the platform more valuable. Every person who contributes to OpenClaw, the underlying framework, makes it more capable. That's a flywheel that a closed-source clone can't replicate.

The MIT license specifically is important. I've seen too many open source projects use licenses that are technically open but practically restrictive — Commons Clause, SSPL, BSL, the various "open source but you can't compete with us" licenses. These create uncertainty. Developers don't know if they can use the project in their product. Companies don't know if they'll face a license change down the road. The result is that people are hesitant to build on top of the project, which defeats the entire purpose of being open source.

MIT is simple. You can do whatever you want with the code. Period. That clarity is worth more than any protection a restrictive license could offer. It means people build on your thing without hesitation, and that ecosystem becomes your moat.

I learned this from watching the React ecosystem. React under MIT has generated more value for Meta than it ever could have under a restrictive license, because the massive ecosystem of React tools and libraries and components and frameworks makes React the default choice for UI development. That wouldn't have happened if every library author had to worry about license compatibility.

There's also a philosophical dimension to this that I care about, which is that CRM data is inherently personal and sensitive, and the software that manages it should be transparent and auditable. You should be able to read every line of code that touches your customer data. You should be able to verify that the software does what it claims and nothing more. Open source under MIT makes that possible. A proprietary cloud CRM asks you to trust the vendor. An open source local CRM asks you to trust the code, which you can read.

Building DenchClaw through Y Combinator was an interesting experience. YC has a strong SaaS culture. The default advice for B2B software is: build a web app, charge a subscription, measure ARR. And that advice is correct for the vast majority of startups. SaaS is a proven model with well-understood metrics and a clear path to scale.

But I think the YC community also understands that the biggest opportunities come from challenging default advice. The whole point of startups is to find things that the conventional wisdom gets wrong. And I think the conventional wisdom that all business software should be cloud SaaS is one of those things that's becoming wrong, or at least wrong for an increasing number of use cases.

The partners we worked with at YC were genuinely curious about the local-first approach. They pushed us hard on the sync story — rightly, because that's where local-first can fall apart — and on the business model. But they also got excited about the performance story and the privacy story in ways that I think reflected a real shift in how sophisticated investors think about software architecture.

One conversation that stuck with me was with a partner who had built and sold a SaaS company. He said something like, "the marginal cost of cloud is supposed to be your advantage as a SaaS company, but it's become a tax instead. You're paying AWS to store data that could just be on the user's machine." That's a sharp observation. Cloud infrastructure costs are a significant line item for most SaaS companies, and for applications where the data could just as easily live on the client, those costs are pure waste — waste that gets passed on to the customer in the form of subscription fees.

DenchClaw doesn't have cloud infrastructure costs for data storage. We don't run databases. We don't manage file storage. We don't pay for compute to serve queries. The user's machine does all of that. Our infrastructure costs are essentially limited to the sync relay server, which is stateless and lightweight, and whatever cloud AI APIs users optionally call. The economics are radically different from SaaS, and that difference will eventually be reflected in pricing.

AI Belongs on Your Machine#

Let me talk about something I've been thinking about a lot lately, which is the relationship between AI and locality.

There's a widespread assumption right now that AI has to be centralized. That you need massive GPU clusters to run models, that inference at scale requires cloud infrastructure, that the economics only work if you amortize the hardware cost across millions of users.

This was true two years ago. It's becoming less true remarkably fast.

The quantization revolution — techniques like GPTQ, GGML, and more recently, the quality improvements in 4-bit and even 2-bit quantization — has made it possible to run genuinely capable language models on consumer hardware. A quantized model running on an M-series Mac gives you response quality that would have required a cloud GPU cluster in 2024. Not for every task, and not at every scale. But for the kinds of tasks a CRM agent needs to do — parsing natural language input, generating structured data, drafting emails, summarizing conversations — local inference is more than sufficient.

And local inference has advantages beyond just privacy. It's faster, because there's no network round-trip. It's more reliable, because there's no API to go down. And it's cheaper per query, because the marginal cost of inference on hardware you've already bought is essentially zero. You're not paying per token. You're not monitoring usage quotas. The GPU in your laptop is already there, already paid for, and for most knowledge workers, dramatically underutilized.

We use a hybrid approach in DenchClaw. Most operations — search, parsing, classification, embedding — run entirely on-device. For operations that benefit from larger models, like complex enrichment or long-form email drafting, we optionally call cloud APIs. But the default is local, and we're pushing more and more to local as the models get smaller and the hardware gets more capable.

The embedding model, which powers semantic search across your CRM data, runs entirely locally. This means you can search your contacts by meaning, not just keywords, and the search happens in milliseconds without sending your data anywhere. You can search for "that startup we talked to in January that was working on climate tech" and get relevant results even if none of those exact words appear in the contact record. This kind of semantic search used to require a cloud service. Now it runs on localhost.

I think this is a harbinger of a much bigger shift. As models continue to get smaller and more efficient, and as consumer hardware continues to get more powerful, the center of gravity for AI inference is going to move from the cloud to the edge. Not entirely — there will always be tasks that require massive models and massive compute. But for the kind of AI that makes everyday software better, the local machine is going to be the primary execution environment. And software architectures that are designed for this — that treat local AI as a first-class citizen rather than a fallback — are going to have a structural advantage.

I want to come back to something I mentioned earlier about the data model, because I think there's a lesson here that goes beyond CRM.

The traditional approach to business software is to define a schema upfront. You decide what fields a contact should have, what stages a deal pipeline should include, what activities are worth tracking. Then you build forms and views around that schema. If a user wants a field that doesn't exist, they submit a request, an admin adds it, the schema is migrated, and the forms are updated.

This is how almost every CRM works, and it's fundamentally at odds with how people actually think about their data. In the real world, the information you want to track about a customer relationship is fluid. It changes based on your industry, your sales process, your stage of growth. A ten-person startup tracking a handful of enterprise deals has completely different data needs than a hundred-person company running high-volume inside sales.

The EAV model with PIVOT views that we use in DenchClaw sidesteps this entirely. There's no predefined schema. Every record is just a collection of attributes, and the attributes are whatever you want them to be. The PIVOT views give you the relational queryability you need for analytics and reporting. And because DuckDB handles the pivot operation natively and efficiently, there's no performance penalty.

But here's the deeper point. This schema-free approach only works well because there's an AI agent mediating the interaction. If a human had to manually manage an EAV data model — deciding what attributes to create, ensuring consistency across records, dealing with the inevitable messiness of freeform data — it would be a nightmare. But the agent handles all of that. When you tell it about a new prospect, it creates the appropriate attributes and populates them consistently. When you search for records, it understands the semantic meaning of attributes even if they're named slightly differently. The AI layer is what makes the flexible data model usable, and the flexible data model is what makes the AI layer powerful. They're symbiotic.

This is, I think, a general pattern for AI-native software. The architecture and the AI have to be designed together. You can't just take a traditional architecture and add AI to it and get the same benefits. The architecture has to be fundamentally different — more flexible, more data-rich, more amenable to programmatic manipulation — because the AI is the primary operator.

I'll end with a prediction, which I'm not very confident about but find compelling.

I think we're going to look back at the 2010 to 2025 era of software and see it as the peak of the cloud monoculture. A period when the industry's default assumption — that software should run on someone else's computer and be accessed through a browser — went largely unquestioned, even for applications where it was a poor fit.

The correction won't be a wholesale abandonment of the cloud. That would be as extreme as the original swing toward it. It'll be more nuanced. Software will run where it makes the most sense for it to run. Collaborative editing, social networks, payment processing — those will stay in the cloud, because centralization is inherent to what they do. But personal productivity tools, development environments, data analysis tools, and yes, CRMs — things where the data is inherently personal or team-scoped, where performance matters, where privacy is a concern — those are going to move to the edge.

The catalyst for this shift is AI. Not because AI requires local execution — although the economics favor it for many use cases — but because AI makes local software capable enough to compete with cloud software on the dimensions where cloud used to win: collaboration, automation, and intelligent features. When your local application has an AI agent that can do things that used to require cloud infrastructure — semantic search, natural language understanding, automated data processing — the tradeoffs shift decisively in favor of local.

DenchClaw is our bet on this future. A CRM that runs on your laptop, powered by an AI agent that reads skill files from your filesystem, storing your data in a DuckDB database that you own and control, syncing with your team through CRDTs when you're online and working perfectly when you're not. It's not the future of all software. But I think it's the future of this kind of software — the kind where your data is yours, where speed matters, and where the AI should be working for you, not for a platform.

You can try it right now. Run a single command in your terminal, and in about thirty seconds you'll have a complete AI-powered CRM running at localhost. Your data stays on your machine. The agent is ready to help. And there's no monthly bill.

That last part might be the most radical thing about it.