The Cloud Was Always a Bad Idea for Personal Data

I want to make a provocative argument: moving personal and business data to the cloud was always a bad idea. Not a bad idea that became apparent in hindsight. A bad idea from the start, obscured by genuine convenience wins that made the tradeoffs feel acceptable — until they didn't.

Let me explain what I mean, because I'm not saying the cloud was wrong for everything. I'm saying it was wrong for a specific class of data: the data that's intimately yours.

The Convenience Trap#

The original pitch for cloud services in the early 2000s was sync. You'd change something on your desktop computer and it would appear on your laptop. Later, on your phone. You didn't have to carry files on a USB drive or email yourself documents. The data just... appeared everywhere you needed it.

This was genuinely valuable. Worth paying for. Worth some tradeoffs.

But the framing gradually shifted. "Sync" became "storage." "Accessible everywhere" became "only accessible through us." The cloud stopped being a synchronization layer for your data and became the custodian of your data. And somewhere in that shift, we accepted a fundamentally different relationship with our own information.

The files on your hard drive are yours. You control them. You can read them, move them, delete them, copy them, encrypt them, share them. No one can take them away from you. No one can change the terms under which you access them. No company going bankrupt can make them disappear.

The files in the cloud are yours, technically. In practice, you access them at the pleasure of a company that can change its pricing, terms of service, or product strategy at any time.

The Breach Problem Is Structural#

Let me talk about breaches, because I think the industry has normalized them to an extent that should alarm people.

The data you put into cloud services goes into massive multi-tenant databases. The cloud provider is storing data from thousands or millions of customers in the same infrastructure. This creates an attack surface that is inherently attractive to sophisticated actors. A successful breach of a major SaaS company doesn't yield one company's data — it yields millions of companies' data. The return on investment for attackers is extraordinarily high.

We saw this with HubSpot in 2022. We've seen it with dozens of other SaaS companies. We'll see it again. The structure of multi-tenant cloud services creates persistent high-value targets. No amount of security investment changes this fundamental economics.

When your data is on your local machine, in an encrypted filesystem, you're a target too — but you're one target among billions, and the attack has to be specifically directed at you. Your data isn't co-located with millions of other companies' sensitive information. The economics of attacking you individually rarely make sense for anyone other than a nation-state adversary.

For most people, most of the time, local-first storage is more secure than cloud storage — not because the local software is better engineered, but because the threat model is fundamentally different.

What We Actually Lost#

I've been thinking about what it means to truly own data, and I think we've forgotten.

Ownership means you can read it without asking permission. You can copy it without limits. You can delete it permanently. You can move it to a different system without the original vendor's cooperation. You can inspect it at any time without going through a sanctioned UI.

When your data is in HubSpot or Salesforce, you can do approximately none of these things without jumping through hoops. Export your data from Salesforce — go ahead, try it. It's a multi-step process with quotas and formats that are optimized for staying in Salesforce rather than leaving it. They call it "data portability" but it's more like "data parole." You can have your data back, but on their terms.

With DenchClaw, your data is in a DuckDB file at ~/.openclaw-dench/workspace/workspace.duckdb. You can open it with any DuckDB client, right now, without asking our permission. You can run any SQL query against it. You can export it to any format. You can delete us from your machine entirely and your data stays exactly where it was.

That's what ownership looks like. And it's so different from what we've accepted from cloud services that I think a lot of people have forgotten it's possible.

The Training Data Problem#

There's a newer dimension to this problem that I think will become much more salient over the next few years: your data being used to train AI models.

When you use a SaaS CRM, your interaction data, your contact data, your deal patterns, your notes — all of this potentially feeds into the vendor's data practices. The terms of service are often ambiguous about whether aggregated, anonymized data from your usage is used for model training. Some companies have been explicit about this. Others have not.

This isn't necessarily malicious. But it's worth thinking carefully about. Your deal notes contain your competitive positioning. Your contact records contain your relationship network. Your pipeline contains your growth strategy. All of this, aggregated across thousands of companies, represents extraordinarily valuable training data for AI models that will be used in the market alongside you.

With a local-first system, there's no ambiguity. Your data never leaves your machine except via the specific API calls you choose to make. When DenchClaw calls an LLM API to answer a question, you can see exactly what data was included in the context. There's no background data pipeline, no aggregation, no training data collection.

The Regulatory Trend Points This Way#

I spend more time than I'd like reading GDPR guidance, EU AI Act implications, and state-level privacy legislation. Here's what I notice: the regulatory trend is toward data residency, data minimization, and user control.

GDPR requires, among other things, that data subjects have the right to access, rectification, and erasure of their personal data. It requires clear consent for data processing. It requires that data not be transferred to jurisdictions without adequate protection. Complying with GDPR as a SaaS company is a significant compliance burden — legal teams, DPAs, data processing agreements, transfer mechanisms.

For a local-first application where the data never leaves the user's machine to begin with, most of GDPR becomes non-applicable. The data is always in the user's jurisdiction, always under their control, always accessible to them without process. You don't need a data processing agreement for data you never process.

This regulatory tailwind is real and I think it's underappreciated. As privacy legislation continues to expand and tighten, the compliance cost of cloud data storage is going to increase. Local-first software won't have that cost.

The Convenience Argument Has Inverted#

Here's the thing I want to close on: the original reason to use cloud services was convenience. But in 2026, local-first software has become more convenient for many use cases, not less.

Installing software is a single command. Updates happen automatically. Your data is always available, even offline. Performance is instant because there's no network round-trip. Setup requires no credit card, no OAuth flow, no configuration of cloud permissions.

The cloud services that were convenient in 2008 because they eliminated installation are now inconvenient because they require internet connectivity, impose rate limits, charge monthly fees, and create export friction when you want your data back.

The convenience argument has inverted. For personal and business data, local-first is increasingly the more convenient choice — and it was always the more secure, more privacy-respecting, more aligned choice.

We moved our data to the cloud because it was convenient. We should move it back because it's better.

Frequently Asked Questions#

Isn't local storage risky if my laptop gets stolen or breaks?#

Your local data should be backed up — Time Machine on macOS handles this automatically. If your laptop is stolen, macOS's encryption protects your data. A stolen encrypted local drive is arguably more secure than a cloud breach that exposes millions of records simultaneously.

What about accessing data from multiple devices?#

DenchClaw supports cross-device access via messaging channels (Telegram, WhatsApp, Discord). For team sync, we're building CRDT-based replication. But for individual users, the phone + laptop combination covers most access patterns.

Cloud providers have massive security teams. Aren't they safer than my local machine?#

Cloud providers have excellent security, but they're also the most targeted organizations in the world. Your local machine is rarely a specific target. Security is about threat model, not just security investment. For personal data, local-first often wins.

What if I need to collaborate with others on the CRM data?#

Team workspaces with sync are in development. Currently, DenchClaw works best for individuals or small teams where one person is the primary CRM operator. The AI agent provides a natural language interface that makes the single-machine model surprisingly workable.

Is this really practical for a real business?#

Yes. Many consultants, founders, and sales professionals run DenchClaw as their primary CRM. The use case is strongest for individuals managing their own pipeline, investor relations, or client relationships — not for 50-person sales teams with complex territory management requirements.

Ready to try DenchClaw? Install in one command: npx denchclaw. Full setup guide →