Your Data Should Live on Your Machine

Here's something that should be obvious but isn't: the most sensitive data your company produces is probably sitting on someone else's computer right now.

Not your source code — most companies worry about that. Not your financial records — your CFO has opinions about where those live. I'm talking about your CRM data. The names and phone numbers of every person your sales team has ever talked to. Internal notes about deal strategy. Competitive intelligence that could move markets. Revenue forecasts that would make your board nervous if they leaked. All of it, typically sitting in a multi-tenant database in us-east-1, controlled by a company whose interests are not perfectly aligned with yours.

We've been building DenchClaw, a CRM that runs locally on your machine, and the more time I spend thinking about why this matters, the more I think the local-first approach isn't just a nice architectural choice for CRM — it's the only defensible one. But to explain why I believe that, I need to talk about the history of computing, the economics of SaaS, and a particular kind of laziness that afflicts entire industries.

The history of computing is, if you squint at it right, a pendulum. It swings between centralization and distribution with a regularity that's almost comical once you see it.

In the beginning, there were mainframes. You had a big machine in a room somewhere, and everyone connected to it through dumb terminals. The computation happened centrally. Your data lived on someone else's machine. If the mainframe went down, everyone stopped working.

Then the PC revolution happened. Suddenly, computation moved to the edge. Your data lived on your machine. You had a copy of Lotus 1-2-3 running on your own hardware, and if the guy down the hall spilled coffee on his computer, your spreadsheets were fine. This was liberating. People loved it. An entire generation of software companies — Microsoft, Borland, Lotus — were built on the idea that software should run on your computer.

Then the internet happened, and we started centralizing again. First it was email — you could run your own mail server, but Gmail was so much easier. Then it was documents — Google Docs meant you didn't have to email Word files back and forth. Then it was everything. By 2012 or so, the software industry had collectively decided that every application should be a web app backed by a cloud database. "SaaS" became the default architecture for every category of business software, and anyone who suggested otherwise was looked at like they'd proposed going back to fax machines.

I think we're at the beginning of another swing. Not all the way back — we're not going to return to shrink-wrapped software in cardboard boxes. But the pendulum is moving, and it's moving for reasons that are genuinely compelling, not just nostalgic.

Why Nobody Questioned the Cloud#

The interesting question is why the cloud assumption went unquestioned for so long. I think there are three reasons, and they're worth examining because they reveal something about how the software industry makes decisions.

The first reason is economic. Cloud software is a wonderful business model. You charge a monthly fee, you have predictable recurring revenue, and your customers can't easily leave because their data is locked in your system. Wall Street loves this. VCs love this. It's the dream business model, and it produces companies with the kind of revenue charts that make fundraising easy. When you're building a software company, there's enormous pressure — from investors, from advisors, from the entire ecosystem — to build a cloud product because that's what gets funded.

The second reason is convenience. Cloud software is genuinely easier to deploy and manage, at least for the vendor. You don't have to worry about what OS your customer is running. You don't have to deal with installation issues. You can push updates instantly. You control the entire stack. For the vendor, the cloud is paradise. And because vendors are the ones who write the marketing copy and set the industry narrative, the convenience of the cloud got framed as a benefit to the customer, which it sometimes is, but not always.

The third reason is herd mentality. Once enough companies in a category go cloud, it becomes the expected architecture. When an enterprise buyer evaluates software, they have a mental checklist, and "cloud-based" has been on that checklist for years. Suggesting a locally-installed alternative triggers an immune response: "That sounds like the old way of doing things." Never mind that the old way of doing things might have gotten some important things right.

But here's what happened while everyone was congratulating themselves on moving to the cloud: the world changed around them. GDPR passed. CCPA passed. India's DPDP Act passed. Data sovereignty became a boardroom concern instead of a compliance footnote. Cloud outages started affecting more and more critical workflows. And AI started processing increasingly sensitive data, raising questions about who has access to your information and what they're doing with it.

It seems to me that we're at one of those moments where the assumptions that defined the last era are breaking down, and the people who notice first will build the next generation of important companies.

What Your CRM Actually Contains#

Let me be specific about why CRM is the category where this matters most.

Think about what a CRM actually contains. Not in the abstract, but concretely. Open up your Salesforce instance or your HubSpot account and really look at what's in there.

There are contact records for every person your sales team has ever spoken to. Names, email addresses, phone numbers, company affiliations, job titles. There are notes from calls — "Sarah mentioned they're unhappy with their current vendor, looking to switch in Q3." There are deal records with exact dollar amounts attached to specific opportunities. There's competitive intelligence — "Lost to Competitor X on price, but their implementation timeline was the real issue." There are internal strategy notes — "Focus on their VP of Engineering, the CTO is a blocker." There are email threads, meeting transcripts, and increasingly, AI-generated summaries of customer conversations.

This is, without exaggeration, some of the most sensitive data a company produces. If your CRM data leaked, your competitors would know your entire pipeline, your pricing strategy, your win/loss patterns, and the names of every decision-maker in every deal you're working. A breach of your CRM is arguably more damaging than a breach of your source code, because source code is hard to exploit without context, but CRM data is immediately useful to anyone in your market.

And yet. This data typically sits in a multi-tenant database managed by a third party. Salesforce has roughly 150,000 customers. Their data is stored in shared infrastructure, separated by software-level tenant isolation, not physical separation. When Salesforce gets a subpoena — and large companies get subpoenaed regularly — they have to respond. When Salesforce has a security incident — and every large company has security incidents — all that customer data is potentially exposed.

I'm not saying Salesforce is negligent. They have thousands of security engineers and spend hundreds of millions on security. But there's a fundamental architectural problem that no amount of spending can solve: if the data is on their servers, they can access it. And if they can access it, so can anyone who compromises their systems, or anyone with legal authority to compel them to hand it over.

The data sovereignty argument for local-first CRM isn't a theoretical nicety. It's a practical concern that gets more urgent every year.

Consider what happens when your CRM vendor gets subpoenaed. In a cloud model, the vendor receives the subpoena, and they have to comply — they have the data, they can access it, and they're legally obligated to turn it over. Your company might not even be notified, depending on the jurisdiction and whether there's a gag order. In a local-first model, the data is on your machine. If someone wants it, they have to come to you. You control the response. Your lawyers handle it. You decide what to produce and what to fight.

Or consider GDPR compliance. Under GDPR, you need to know where personal data lives, who has access to it, and be able to delete it on request. With a cloud CRM, answering these questions requires trusting your vendor's documentation and hoping they actually delete the data from backups and replicas and analytics pipelines when you ask. With a local-first CRM, the answer is simple: the data is in a file on this machine. I can show you. I can delete it right now. I can prove it's gone.

This might sound like a minor administrative difference, but anyone who's been through a GDPR audit knows it's not. The ability to point at a file on disk and say "that's where the data lives" is categorically different from pointing at a vendor's SOC 2 report and saying "they promise they're handling it correctly."

There's also the issue of emerging regulations. India's Digital Personal Data Protection Act, Brazil's LGPD, China's PIPL, and a dozen other frameworks are creating a patchwork of data residency requirements that make cross-border data flows increasingly complicated. If your CRM data lives on a server in Virginia, and you have customers in Germany, and your sales team is in Singapore, you potentially have a compliance problem that involves three different regulatory frameworks. If your CRM data lives on each salesperson's laptop, the compliance question is much simpler: the data is in the jurisdiction where the person is.

I know this sounds like a problem that only matters for large enterprises, but it's moving downmarket fast. I've talked to 30-person startups that have lost deals because they couldn't answer data residency questions satisfactorily. The buyer said "we need our data to stay in the EU," and the startup said "well, our CRM vendor uses AWS in us-east-1, but they have a data processing agreement..." and the buyer's eyes glazed over and the deal died.

Speed as a Category Difference#

Now let me talk about performance, because I think this is the argument that's most underappreciated.

When people hear "local-first is faster," they think about it quantitatively. Oh, you save 100 milliseconds on each request. That's nice, but is it really a big deal?

It is a big deal, but not for the reason they think. The difference between local and cloud performance isn't incremental — it's categorical. It's not that a local CRM is a little faster. It's that a local CRM enables interactions that are architecturally impossible with a cloud CRM.

Think about search. In a cloud CRM, when you type a character in the search box, here's what happens: the browser serializes a request, does DNS resolution, performs a TLS handshake (on the first request at least), sends the request across the network to a data center that might be 50 milliseconds away, the load balancer routes it to an application server, the application server queries the database, the database runs the query, the results come back up the stack, across the network, and into your browser. If you're lucky, this takes 200 milliseconds. If you're on a spotty connection, or the vendor's servers are under load, it might take 500 milliseconds or more.

In a local CRM running on DuckDB, when you type a character in the search box, the application reads from a file on disk. The data is already in memory because DuckDB is smart about caching. The query executes in under a millisecond. The results appear so fast that it feels like the application is reading your mind.

This isn't just a faster version of the same experience. It's a qualitatively different experience. It's the difference between "I can search my CRM" and "I can think through my CRM." When search is instant, you use it differently. You search more. You explore connections you wouldn't have bothered to explore if each search took half a second. You use search as a way of thinking, not as a way of finding a specific thing you already know exists.

The same applies to navigation. In a cloud CRM, every screen transition involves a network request. You click on a deal, you wait. You click on a contact, you wait. You go back to the list, you wait. Each wait is small, but they accumulate into an experience that feels sluggish, like walking through water. You stop exploring because each click costs you time.

In a local CRM, navigation is instant. Click on a deal — it's there. Click on a contact — it's there. Go back — it's there. The application feels like an extension of your thinking, not an obstacle between you and your data. This is the same insight that made Apple's original iPhone feel magical: when the interface responds at the speed of thought, the technology disappears and you're just interacting with your information.

And then there are AI features. Every CRM is adding AI now, and for good reason — there's enormous value in summarizing call transcripts, suggesting next actions, scoring leads, and analyzing pipeline patterns. But in a cloud CRM, every AI interaction involves sending your data to an inference endpoint, waiting for the result, and hoping the round trip is fast enough to be useful. In a local CRM, you can run AI models locally, on the same machine as your data. The latency disappears. You can have AI features that respond in real-time as you navigate your CRM, surfacing insights without you having to ask for them.

I think the performance argument alone is sufficient to justify local-first CRM, but let's talk about resilience too.

Cloud software has a dirty secret: it goes down. Not often — the big providers are quite good — but when it goes down, it goes down for everyone at once, and it always seems to happen at the worst possible time.

Salesforce had a significant outage in September 2025. For several hours, thousands of sales teams worldwide couldn't access their pipeline. Salesforce had another in 2019 that lasted over 15 hours and was caused by a database script that accidentally gave every user in the system broader data access than intended. Microsoft 365 has had multiple outages affecting tens of millions of users. Even AWS, the gold standard of cloud infrastructure, has had outages that took down huge swaths of the internet.

The thing about these outages is that they're not bugs you can fix. They're a fundamental property of centralized systems. When everyone depends on the same infrastructure, a single failure affects everyone. This is the exact same problem that mainframes had in the 1970s, and it's the exact same reason the PC revolution happened.

With a local-first CRM, you simply don't have this failure mode. Your CRM works on an airplane. It works when your office internet goes down. It works when your vendor's entire cloud infrastructure is on fire. Because the application and the data are on your machine, the only thing that can stop you from using your CRM is your machine breaking. And that's a failure mode you control — you have backups, you have IT support, you can swap to another machine.

I've heard from sales leaders who say they've lost deals because their CRM was down during a critical call. The prospect asked about pricing history, and the rep couldn't pull it up. The prospect asked about previous discussions, and the rep had to wing it. These aren't theoretical scenarios. They happen, and they cost real money.

The Collaboration Problem#

Now, the obvious objection to everything I've said so far is: "But what about collaboration? My team needs to share data. That's the whole point of a CRM."

This is a totally valid concern, and I want to be honest about it: collaboration is the hardest problem in local-first software. It's the reason most people reflexively assume that local-first means single-user. And for a long time, they were right.

But the computer science has caught up. The key innovation is something called CRDTs — Conflict-free Replicated Data Types. Without going too deep into the theory, CRDTs are data structures that have a remarkable property: they can be modified independently by multiple users on multiple devices, and when those devices reconnect, the modifications merge automatically without conflicts. No merge conflicts. No "someone else edited this, please resolve." Just seamless, deterministic merging.

The way this works at a high level is that every change is tagged with enough metadata — timestamps, logical clocks, user identifiers — that the system can reconstruct a consistent view even when changes arrive out of order. If two salespeople update the same contact record simultaneously — one updates the phone number, the other adds a note — the CRDT ensures both changes are preserved. If they both change the phone number (the classic conflict scenario), the CRDT uses a deterministic rule (like "most recent write wins") to resolve it without human intervention.

This is the same technology that powers the collaboration features in Figma, Apple Notes, and several other applications that feel magical. You can work offline, come back online, and everything just merges. It feels like science fiction if you grew up dealing with merge conflicts in Git, but the math actually works.

In DenchClaw, we use CRDTs for all shared data. When your team syncs pipeline data, each device sends its changes to a sync server, and those changes merge seamlessly on every other device. But here's the critical part: the sync server never sees your actual data. All the sync traffic is end-to-end encrypted. The sync server handles opaque, encrypted blobs — it knows that device A has changes for device B, but it has no idea what those changes contain. It can't read your customer names, your deal values, your internal notes. It's a glorified mailbox that can't read the mail.

We also implement selective sharing, which I think is an underappreciated feature for CRM specifically. Not everything in a CRM needs to be shared. A sales rep's personal notes about a call — "This prospect seems flaky, might not be a real opportunity" — shouldn't necessarily sync to the team pipeline. With selective sharing, personal notes stay local on the rep's device. Shared pipeline data — deal stages, close dates, forecasts — syncs across the team. Admins control what crosses the wire and what stays private.

This might seem like a minor feature, but I think it actually changes how people use their CRM. One of the well-known problems with CRM adoption is that reps don't put their real thoughts in the system because they know their manager can see everything. So they write sanitized notes that are basically useless. With selective sharing, reps can keep their raw, honest notes private while still contributing structured data to the team. It's a better design because it acknowledges a real human behavior instead of pretending it doesn't exist.

Why DuckDB#

Let me take a brief digression to talk about our technology choices, because I think they reveal something interesting about how to think about architectural decisions.

When we started building DenchClaw, one of the first questions was: what database? The obvious choices were SQLite (the default embedded database) or PostgreSQL (the default server database). We chose neither. We went with DuckDB.

DuckDB is an embedded analytical database. Like SQLite, it runs in-process — no separate server, no network connection, no external dependencies. Your entire CRM database is a single file on disk. But unlike SQLite, DuckDB is designed for analytical queries. It uses columnar storage, which means it's fast at the kind of queries CRM users actually run — aggregate pipeline by stage, show me all deals that closed last quarter, what's our average deal size by segment.

SQLite is wonderful for transactional workloads — inserting and updating individual records. But CRM isn't primarily a transactional workload. Yes, you insert and update records, but the queries that actually matter are analytical. When a sales leader opens their CRM, they want to see their pipeline broken down by stage, by rep, by close date. They want to search across thousands of contacts. They want to run reports that aggregate and filter and group. These are analytical queries, and DuckDB is dramatically faster at them than SQLite.

The choice of DuckDB also has a nice property for local-first architecture: because the entire database is a single file, it's trivially portable. You can copy your CRM to a new machine by copying a file. You can back it up by backing up a file. There's no database server to migrate, no connection strings to update, no cluster to manage. Your CRM data has the same simplicity as a spreadsheet file, but with the power of a real database behind it.

We also made a deliberate choice to store documents as markdown files and configuration as YAML, rather than putting everything in the database. This means your CRM data is not only on your machine — it's in formats you can read and manipulate with standard tools. If DenchClaw disappeared tomorrow, your data would still be right there on your filesystem, perfectly readable. No export process, no data migration, no vendor lock-in. Just files.

I think this is an important philosophical point. Software vendors love to talk about avoiding lock-in, but most of them define lock-in very narrowly — "you can export your data as a CSV!" A CSV export of a CRM that has attachments, rich text notes, custom fields, and relationship data is not a real escape hatch. It's a fig leaf. Real freedom from lock-in means your data is always in a format you control, on a machine you control, without needing the vendor's cooperation to access it.

The Honest Tradeoffs#

Now, I said I would be honest about tradeoffs, and I think intellectual honesty is important here. Local-first is not strictly better than cloud in every dimension. There are real things you give up.

The first is instant onboarding. With a cloud CRM, a new team member goes to a URL and they have access to everything. With a local-first CRM, they need to install the application and sync the data to their machine. We've made this as painless as possible — you run a single command, the app starts up, and sync begins — but it's still a step that doesn't exist with cloud software. For a small, fast-moving team that's adding people every week, this friction matters.

The second is centralized admin control. Cloud CRMs give administrators a god-view: they can see everything, change permissions, pull reports across all users. In a local-first model, some of this is inherently harder. We provide admin capabilities through the sync layer, but they're not as instantaneous as they are in a cloud model. If an admin revokes a user's access, they can revoke sync permissions immediately, but any data already synced to that user's device is, by definition, already on their device. This is actually more honest — in a cloud CRM, when you revoke access, the user can't see the data in the UI, but they might have screenshots, exports, or cached data. Local-first just makes explicit what was always true.

The third tradeoff is real-time collaboration on the same record. With CRDTs, collaboration works well, but there's an inherent latency when syncing across devices. If two people are looking at the same deal record and one of them changes the close date, the other person won't see the update until the sync happens. This can be near-instantaneous when both devices are online, but it's not the same as Google Docs-style real-time co-editing. For CRM, I think this is fine — you rarely have two people editing the same contact record at the same moment — but it's worth acknowledging.

The fourth is mobile experience. Running a full local-first CRM on a phone is harder than showing a web app in a mobile browser. We're building mobile sync capabilities, but the experience of running DuckDB on an iPhone is different from running it on a MacBook with 16 gigs of RAM. This is a real limitation, and it's one we're actively working on.

I list these tradeoffs because I think one of the most damaging things a company can do is pretend its architecture has no downsides. Every architectural choice is a set of tradeoffs, and the honest thing to do is be explicit about them. But having listed them, I want to say: I think the tradeoffs of local-first are much better than the tradeoffs of cloud-first for CRM specifically. The things you give up are manageable engineering challenges. The things you gain — data sovereignty, performance, resilience — are fundamental.

The Broader Movement#

Let me talk about the broader trend, because I think what's happening in CRM is part of something bigger.

Linear built their project management tool with local-first principles, and it's the fastest project management tool most people have ever used. The entire interface is rendered locally, and changes sync in the background. When you use Linear, you immediately feel the difference — everything is instant, there are no loading spinners, and it just works on a plane. Linear didn't do this as a gimmick. They did it because it produces a better product.

Figma renders everything on the client. The collaboration is remarkable, but under the hood, all the computation happens on your machine. The server handles coordination, not rendering. This is why Figma feels so much faster than traditional cloud design tools — you're not waiting for a server to render your designs.

Apple Intelligence processes AI tasks on-device by default. When you summarize a document or generate a reply to an email, that computation happens on your Mac or iPhone. Apple only falls back to cloud processing when the task requires more compute than the device can handle, and even then, they run it on dedicated Apple silicon servers with attestation guarantees. Apple made this choice because they understand that privacy is a feature, not a constraint.

The pattern is clear: the best software experiences are being built by companies that move computation to the edge. And the ultimate edge is the user's own device.

I think this trend will accelerate for several reasons. Hardware is getting more powerful — the M-series chips from Apple have made "running real software locally" viable in a way it wasn't five years ago. AI models are getting smaller and more efficient — you can run a capable language model on a laptop now. Network connections are getting faster in cities but remain unreliable in many places where work actually happens. And privacy regulations are getting stricter, making the compliance burden of cloud software heavier every year.

There's also an underappreciated economic argument. Cloud software requires the vendor to run servers, which costs money, which means the vendor needs to charge higher prices or sacrifice margins. Local-first software offloads computation to the user's hardware, which the user has already paid for. This doesn't mean local-first software should be free — there's still the cost of development, support, and sync infrastructure — but the cost structure is fundamentally different. You're not paying for compute every time you run a query.

I want to address one more thing, because I hear it a lot when talking to enterprise buyers: "Isn't local-first software just installed software? Aren't we going backwards?"

This is the most common objection, and it reveals a deep misunderstanding. The old model of installed software had many problems: difficult installation, manual updates, no collaboration, version compatibility issues, poor security. Local-first software has none of these problems.

DenchClaw installs with a single command. Updates are automatic. Collaboration happens through encrypted CRDT sync. The application is always on the latest version because it updates itself. Security is better than cloud because the attack surface is smaller — there's no multi-tenant server to compromise.

The thing that was bad about old installed software wasn't that it ran locally. It was that it was isolated — no collaboration, no sync, no updates. Local-first architecture keeps the good parts of running locally (performance, privacy, resilience) while using the internet for the things the internet is actually good at (synchronization, updates, collaboration).

It's more accurate to think of local-first as a synthesis of the best properties of installed software and cloud software. You get the speed and privacy of local, with the collaboration and always-updated qualities of cloud. It's the best of both worlds, not a step backwards.

What Buyers Actually Say#

When I talk to enterprise buyers about DenchClaw, the reaction is consistently interesting. The IT and security people immediately get it. They light up when I explain that the data never leaves the company's machines. They've spent years filling out security questionnaires and negotiating data processing agreements, and the idea of a CRM where the data simply stays on their infrastructure is enormously appealing.

The sales leaders have a different reaction. They're initially skeptical — "will it be as powerful as Salesforce?" — but once they use it, the speed wins them over. The experience of a CRM that responds instantly to every click is, for many of them, genuinely revelatory. They didn't realize how much the latency of their cloud CRM was affecting their daily work until they used something without that latency.

The most interesting reaction comes from founders and CEOs. They think about it strategically. "So you're saying that if we use this, our CRM data is genuinely ours? No vendor can access it? No subpoena to a third party?" When I confirm, I can see the wheels turning. They start thinking about all the sensitive information in their CRM that they hadn't really considered as a security risk because cloud storage seemed so normal.

One founder told me something that stuck with me. He said, "I spent months negotiating a SOC 2 compliance clause with our CRM vendor, and at the end of it, I realized I was negotiating for the right to trust them with my most sensitive data. The local-first answer just eliminates the trust requirement entirely." He was right. The best security architecture isn't one that requires trust — it's one that makes trust unnecessary.

I think we're at the beginning of a major shift in how enterprise software is built and consumed. The cloud era isn't ending — there are many categories where cloud is the right architecture. But for categories where data sensitivity is high, performance matters, and offline use is valuable, local-first is going to be the default architecture within a decade.

CRM is the obvious first category because it hits all three criteria: the data is extremely sensitive, performance directly affects user adoption (which has always been CRM's biggest problem), and sales reps are often mobile, on planes, in conference centers with bad wifi, visiting customers in offices with locked-down networks.

But I think the pattern will extend to other categories too. Legal document management. Healthcare records. Financial modeling. HR systems. Any category where the data is sensitive enough that "trust us, we're SOC 2 certified" shouldn't be a satisfying answer.

The pendulum is swinging. And this time, it's not swinging all the way back to isolated installed software. It's swinging to something new: software that runs on your machine, with your data, under your control, but connected to the world when you want it to be. Software that's local by default and networked by choice.

I think this is where the best software will be built for the next decade. We're building one piece of it with DenchClaw. If you want to see what a local-first CRM feels like, install it and try it. It takes one command to set up and about thirty seconds to understand why this matters. Your data will be right there, on your machine, in files you can read. No cloud required.

That's the answer to "where does our data live?" It's on your machine. It always was yours. We just stopped pretending otherwise.