What We Got Wrong About the Cloud

I've been thinking about the moment cloud computing became the obvious default. Somewhere around 2010, the question stopped being "should we build on the cloud?" and became "why wouldn't we?" That shift happened so fast, so completely, that we forgot to ask whether the underlying assumptions were actually true.

Building DenchClaw — a local-first, open-source AI CRM — has forced me to sit with that question. And the honest answer is: we got a lot wrong. Not maliciously, not stupidly, but confidently and collectively. The cloud narrative was so compelling that we treated its premises as axioms when they were really just bets.

Here's what I think we actually got wrong.

We Confused "Accessible Anywhere" with "Better"#

The original pitch for cloud software was about access. Your data, anywhere, any device. That was genuinely valuable. Before cloud sync, losing your laptop meant losing your work. Before SaaS, software upgrades were CDs your IT department scheduled months in advance.

But "accessible anywhere" got quietly upgraded to "the cloud is categorically superior." That's a different claim, and it doesn't hold up to scrutiny.

When I use DenchClaw locally, my CRM queries run against DuckDB at columnar speeds — we're talking milliseconds for aggregations that would take seconds on a remote API. The data never leaves my machine. There's no latency spike when Salesforce's API is having a bad Tuesday. There's no pricing tier that throttles my export. The machine I own is doing the computation.

Accessibility is a distribution problem. It's solvable in ways that don't require surrendering your data to someone else's server. We just stopped looking for those solutions once the SaaS model became financially dominant.

We Underestimated How Much Reliability Depends on Someone Else's Uptime#

Here's a pattern I've seen play out dozens of times: a startup picks the right tools, builds a great product, gets acquired or pivots, and all their users' data evaporates or becomes inaccessible. Rdio. Sunrise Calendar. Mailbox. Sparrow. The graveyard is long.

The cloud promised reliability. What it actually delivered was someone else's reliability, which is a fundamentally different thing. When HubSpot has an outage, your sales team can't work. When a SaaS raises prices 40%, you either pay or spend three months migrating. When a founder decides the product doesn't fit their roadmap anymore, your data has a sunset date.

None of this was hidden from us. We just kept accepting it because the alternative — running your own infrastructure — felt more unreliable. And for a long time, for many use cases, it was. Setting up databases was painful. Managing servers was painful.

But here's what changed: embedded databases like DuckDB made local storage trivially robust. M-series Macs made local computation genuinely powerful. The assumption that "local = fragile" aged out without us noticing.

We Made Privacy a Compliance Problem Instead of a Design Problem#

I'll say something that might sound obvious but wasn't obvious to me until I built DenchClaw: if your data never leaves your machine, you don't have a privacy problem.

Not "you have a smaller privacy problem." Not "you have a compliant privacy posture." You literally don't have the problem. There's nothing to breach. There's no data at rest on someone else's server waiting to be subpoenaed or hacked.

Cloud companies discovered they could monetize data, so they built business models that required data collection. Then GDPR happened, and privacy became a compliance discipline — consent banners, data processing agreements, breach notification timelines. An enormous apparatus for managing the consequences of a design decision that was never necessary.

When I was building early enterprise tooling at YC, I watched customer conversations devolve into lengthy legal reviews about where data was stored. Which jurisdiction. Which subprocessors. Which encryption standards. Enormous friction, enormous cost, all in service of a question that local-first architecture simply doesn't ask.

We Priced Out Small Operators#

The SaaS pricing model has a specific shape: free tier (limited), then a per-seat jump that suddenly makes the product expensive, then enterprise tiers that require a conversation with a sales rep.

This isn't incidental to SaaS — it's core to it. You need recurring revenue to pay for servers, support, engineering. The model is self-reinforcing.

But it means that the small operator — the independent consultant, the early-stage founder, the one-person sales team — either lives in hobbled free tiers or stretches for pricing that doesn't match their usage. HubSpot's starter tiers are functional. Their actual capable features are not cheap.

DenchClaw runs npx denchclaw and then it's just... yours. The cost is your hardware, which you already own. There's no per-seat fee because there's no server to maintain. The economics of local-first are fundamentally different, and they advantage individuals and small teams rather than enterprises.

We Assumed the Cloud Model Would Scale to AI#

This is the assumption that really concerns me now.

Cloud CRMs are retrofitting AI onto architectures built for forms and pipelines. Salesforce Einstein. HubSpot AI. These are genuinely impressive engineering efforts. But they're working against a fundamental constraint: the AI has to ingest your data through their API, reason about it on their servers, and return a response.

That creates a ceiling. Your AI assistant can only know what you've entered into the CRM. It can't browse the web as you, understand your email context, open your calendar, or combine all of that into genuine situational awareness. The data is siloed by the architecture.

DenchClaw's AI agent runs locally. It can use browser automation with your existing Chrome profile — your logged-in sessions, your actual context. It can read files. It can run SQL against your local DuckDB. The intelligence isn't bounded by what you've entered into a form.

This is the architectural advantage that cloud CRMs cannot replicate without fundamentally reinventing themselves. The data model isn't incidental — it's load-bearing.

We Forgot That Vendor Lock-In Is a Bug, Not a Feature#

Every SaaS company talks about their ecosystem. Integrations. Marketplace. Platform. What they're building is switching costs, and they're honest about it in investor presentations if not in customer conversations.

HubSpot's great power is that your entire funnel — contacts, emails, pipelines, website analytics — lives there. Moving out requires exporting everything, reformatting it, and rebuilding your workflows. Most companies just don't. The inertia is the point.

Open-source, local-first architecture flips this. DenchClaw uses an MIT license specifically because we want the code to be forkable, modifiable, extendable. If we make decisions you don't like, you can take the codebase and go your own direction. If we build something wrong for your use case, you can fix it. The skills system — markdown SKILL.md files that teach the agent capabilities — is designed to be authored by anyone.

We've watched the SSPL debates in the open-source community. License decisions that look like open-source but include cloud deployment restrictions. We chose MIT because we believe the ecosystem benefits outweigh the competitive exposure, and because we think you should actually own the software you run. Not "licensed to use." Own.

What "Local-First" Actually Means#

I should be precise here, because "local-first" has started to mean different things in different conversations.

For DenchClaw, local-first means:

1. Data lives on your machine. DuckDB database file, your filesystem. Not a server we control.
2. Compute runs on your machine. Queries, AI reasoning, browser automation — your hardware.
3. You can use it offline. Nothing requires a network call to function.
4. You can extend it. Open-source, MIT license, skills system.

It doesn't mean anti-collaboration or anti-sync. You can share a DenchClaw database across devices if you want. You can run it on a server you control. Local-first is about where the source of truth lives and who controls it, not about network access per se.

The Reckoning#

I don't think cloud computing was a mistake. I think it was the right bet at the time, and it unlocked enormous value. But bets don't stay right forever. The hardware assumptions that made cloud superior have shifted. The privacy landscape has shifted. The AI capabilities available at the edge have shifted.

We're at a moment where the default assumption — "new software should be cloud-first" — deserves to be questioned. Not as a nostalgic return to local software, but as a principled re-examination of what we actually want software to do.

When I look at what DenchClaw can do — running an AI agent that browses the web as you, maintains a DuckDB database of your relationships, executes skills you've defined in plain markdown — I see something that cloud architecture structurally can't replicate at the same level. That's not a marketing claim. It's an architectural fact.

The cloud got a lot of things right. It got some foundational things wrong. Acknowledging that is how we build better.

FAQ#

Isn't local software less reliable than cloud? Not anymore. Embedded databases like DuckDB are extremely stable. The real reliability question is whether you trust your hardware more than a third-party SaaS. For most use cases, modern laptops with decent backups are extremely reliable.

What about collaboration — doesn't cloud make that easier? Cloud makes one particular form of collaboration easy: everyone accessing the same server. But collaboration is a solved problem with different approaches — shared filesystems, sync tools, self-hosted servers. Local-first doesn't prevent collaboration; it just requires thinking about it differently.

What happens if DenchClaw shuts down? Your data is in a DuckDB file on your machine. The software is MIT-licensed and open-source on GitHub. You keep everything. This is fundamentally different from a SaaS shutdown where your data may become inaccessible.

Can local-first software ever match cloud software's features? In some categories, yes — and in AI-assisted personal productivity, local-first has architectural advantages cloud can't easily match. In others, like massive real-time multi-user applications, cloud has genuine advantages. The question is what category you're in.

Why is DenchClaw free? Because the cost structure of local-first software is different. We don't pay for servers to store your data. Our costs are development, not infrastructure. That lets us distribute the software free while building sustainable business models around hosted versions, enterprise features, and the skills marketplace.

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