Is OpenClaw worth setting up for my business?

Every week I see more founders asking the same thing: should I set up OpenClaw?

If you're about to try it, already hit a technical wall with the setup, or trying to decide if it's worth your weekend, read on. Or send this to Claude to summarize and pull out the links.

Tl;dr

• OpenClaw has 230,000+ GitHub stars since launching in November 2025, and its creator, Peter Steinberger, was recently hired by OpenAI.
• OpenClaw works. It's an incredibly impressive open-source project and the attention it's getting is earned.
• But if you're running a business with a small team and no engineers, it almost certainly isn't for you right now. Not because it's pure hype (it's not), but because it was built for a different person solving a different problem.

Why should you listen to me?

I'm running my own OpenClaw, and so are most of our team: both as personal assistants and to stress-test a subset of tasks we're building Toyo to handle. Many founders in my network and a handful of friends have also set up OpenClaws, and we've been comparing notes as we learn.

I'm not a software developer. But between debugging my own OpenClaw, comparing notes with people who've gone way deeper, and having the same conversation with a bunch of different people, at this point I figured writing it down could be helpful for others.

What people are actually doing with OpenClaw

It feels like every other post on my timeline is someone demoing OpenClaw agents doing something incredible: making money while they sleep, shipping apps to the App Store, rebuilding entire websites without opening a laptop (these results are real, receipts below). If you're a founder watching from the outside, the FOMO can feel intense.

A few of my favourites:

• Nat Eliason gave his agent Felix a goal and a bankroll. The public claim: it generated over $14,000 in about three weeks, building a site, an info product, and an audience pipeline while he slept. Nat is building in public and you can follow @FelixCraftAI to see what it does next.

• Dave Kiss demonstrated just how easy OpenClaw can make it to rebuild your personal website:

• CopyKat Capital submitted their first app to the iOS App Store, mostly done via instructing his OpenClaw on Telegram:

• Dhruval Golakiya set up a daily loop where his agent reads unread emails every morning, sends a summary, and auto-creates todos that sync to a team CRM. Not a one-off prompt; a compounding automation that runs while he does other things.

People are clearly using OpenClaw to get real work done. But what does it actually take to do yourself?

The cost nobody's demoing

The 90-second clips on X show the output, but not the weekend and evenings you'll spend getting there.

OpenClaw assumes a very specific kind of user

One thing that's become obvious comparing notes with other OpenClaw users: this tool quietly assumes a certain personality type, someone who:

• Thinks in systems
• Enjoys debugging
• Doesn't mind spending evenings iterating on tooling
• Is comfortable holding a lot of operational complexity in their head
• Is willing to carve out real time for infrastructure work

If that's you, OpenClaw is extraordinary. But many founders I know actually don't want to become AI platform operators. They want leverage, outcomes, and to spend their time working on their business, not tinkering with and maintaining the technical systems that are supposed to run it.

Unless you love everything in the list above, the gap between what OpenClaw enables and what most founders have time for will probably just feel like friction.

You become your own platform team

Setting up OpenClaw means working in the terminal. You're wiring APIs, making hosting decisions, debugging dependencies, and configuring agent permissions. Even with coding assistants helping you through the setup, you're still doing ops: choosing which model to use, managing token budgets, deciding how to structure agent workspaces.

OpenClaw is designed for people who are comfortable here. Peter built it as a developer tool, and for developers it's extraordinary. But if your reaction to "open a terminal and run this command" is discomfort, you're likely to end up fighting the tool instead of using it.

I say this as someone who only started getting comfortable in the terminal last year. Claude Code changed that for me, but even with our team's range of technical experience, we've cumulatively spent a lot of real time to tune our own OpenClaw setups, and our usage is still a work-in-progress.

I wanted to do it right. Rather than the YOLO approach I'd seen many take, I spent extra time reading about security best practices to lock down the machine, ensure read-only access to a handful of accounts, making sure every connection was configured carefully, etc. By the end of it, my setup passed a security audit, but felt nowhere near as immediately capable as the OpenClaw demos I was seeing people post about. There's a direct trade-off between security and capability, and optimizing for security will slow you down. You have to decide that balance for yourself.

Here's how it usually goes:

1. After doing a bunch of research, you clear a Saturday to get it working. You make progress.
2. Something breaks.
3. You debug for two hours, fix it, and run into the next issue.
4. By Sunday evening you have something running, but you've spent your weekend on infrastructure instead of your business. And now you need to maintain it.

And "maintain" isn't a figure of speech. The OpenClaw issue tracker shows recurring classes of breakage that map directly to founder pain:

• A critical bug where the memory plugin stops all persistence after an update, causing permanent loss of conversation history.
• Users reporting days of agent context lost to silent compaction.
• Cron schedulers that stop firing after gateway startup, causing scheduled automations to silently die while the gateway appears healthy.
• Gateway restarts that corrupt sessions and trigger infinite loops until someone manually intervenes.

A friend (who didn't want to be publicly named as an OpenClaw freak for security reasons) said: "It's like developing your own software: things break, and you end up debugging the agent stack."

If your use case depends on scheduled tasks, email triage, or long-running agent projects, budget some time for monitoring and intervention. This isn't set-and-forget.

Security is a real problem

Agents need access to be useful. Email, calendar, files, APIs. The more access you give them, the more they can do. But also: the more attack surface you create.

This isn't theoretical:

• Internet scans tracked OpenClaw instances exposed to the public internet growing from roughly 1,000 to over 21,000 in under a week.
• A high-severity 1-click exploit chain (CVE-2026-25253) was disclosed and patched; it could exfiltrate auth tokens and lead to remote code execution through a single malicious link.
• The ClawHub skills marketplace (where users share agent capabilities) has already been used for malware distribution: malicious plugins disguised as trading bots and financial assistants, stealing crypto wallets, browser passwords, and cloud tokens. OpenClaw has since partnered with VirusTotal to scan skills, but the supply chain risk is ongoing.

Prompt injection is the other big risk. It doesn't require someone to DM your bot. It can arrive through anything the agent reads: web pages, emails, docs, attachments, pasted logs. OpenClaw's own security docs are unusually direct about this. They describe the project as "both a product and an experiment" and are clear that there is no perfectly secure setup. Their advice: start with the smallest access that still works, then widen as you gain confidence.

For example: someone sends you an email with hidden instructions embedded in white text. Your agent reads the email, follows the hidden instructions, and now the attacker has access to everything the agent can touch. One compromised email, and the chain reaction looks like this:

None of this is hypothetical: recent reporting describes a prompt injection exploit in another coding agent being used to spread OpenClaw itself.

There's also a more basic infrastructure question that's easy to overlook: running OpenClaw means running a server. On your machine, or on a VPS you manage. If you want agents to be reachable (which is the whole point) you're opening ports, poking holes in your firewall, making decisions about network exposure that most founders have never had to make. These aren't decisions you want to get wrong, and for a non-technical operator, even knowing what "getting it wrong" looks like is part of the problem.

Context and memory are fragile

Here's the part that doesn't show up in any demo: agents don't know your business.

We experienced this firsthand. As an experiment, we added an OpenClaw sub-agent into our team Slack, a digital teammate with access to business context. That agent was set up to share only some context with my personal OpenClaw agent in Telegram. At some point, the context boundaries blurred: my personal agent got confused and started behaving as if it were the marketing agent. I didn't notice for a couple of days. The failure wasn't dramatic. It was quiet, and that's what made it worse.

Here's what "contextually wrong" actually looks like: I asked my agent to change its model routing (something it confidently assured me it could do). It immediately broke itself. I spent over an hour with Claude Code diagnosing malformed JSON files the agent had created. One tip: never rely on your OpenClaw agent's confidence in the exact steps it recommends to fix itself.

More experienced developers version-control their OpenClaw configs better than I had, and roll back when something breaks. Mine wasn't fine-grained enough to save me in that instance. If "roll back to a previous commit" isn't part of your vocabulary, you may be looking at hours in the command line trying to get your agent working again. That's not a place most people running a business can go.

None of this is free, either

The costs that matter most aren't on your API bill.

Software engineer Chris Boyd gave his OpenClaw access to iMessage:

My wife called from the couch: "DID YOU GET HACKED?"

"Kinda? I accidentally hacked myself."

The agent treated his recent contacts list as a target list and fired off over 500 unsolicited messages to him, his wife, and random contacts before he could pull the power cord.

Meta's alignment director Summer Yue had her agent delete 200+ emails from her primary inbox after weeks of it working perfectly on a test inbox. The cause: context compaction dropped her "confirm before acting" instruction, and the agent kept going while ignoring her stop commands. She had to physically run to her machine to kill the process. When an agent asks you to confirm before acting, that's a suggestion the model is choosing to follow, not a technical safeguard. If the instruction gets lost in context, the agent will just act. These aren't edge cases from careless users. Boyd is an engineer. Yue leads AI safety research at Meta. If their agents can go rogue on routine tasks, yours can too.

The direct costs add up fast, too: Users routinely report burning through millions of tokens per day. One user hit 5.7 million overnight on a simple daily email summary. Tech blogger Federico Viticci documented a $3,600 monthly bill. Realistic small business usage can easily blow past $150/month in API costs alone, and complex workflows can push that cost far higher.

You become, in effect, a memory manager. That's a job most founders didn't sign up for.

OpenClaw is single-player by design

All of the friction above applies to a single user. When you try to use OpenClaw with a team, you hit a more fundamental problem.

Peter Steinberger made this explicit in a tweet this week while working through another round of security reports:

"The security model of OpenClaw is that it's your PERSONAL assistant (one user - 1...many agents)."

He went on to say he'd closed around twenty reports from people trying to force OpenClaw into a multi-user architecture, something it was never designed for and that would introduce "loads of needless complexity" and "unnecessary bugs that won't benefit the vast majority of users."

This is the right call for his project. Keeping the architecture simple lets Steinberger and the community ship fast and maintain security for the audience it's designed for.

But if you're a founder thinking about deploying agents across your team, it means you need to understand what's missing.

What multi-user looks like (it doesn't)

There's no concept of user-level context versus organization-level context. An agent can't know that certain information belongs to your head of sales and other information is shared across the company. There's no permission scoping per team member. If multiple people interact with the same agent gateway, their conversations can bleed into each other: Alice's private context showing up in Bob's session.

People have tried to solve this by running separate OpenClaw instances per person. That works, technically. But now you're managing multiple servers, each with its own credentials, its own memory, its own configuration. You've become an AI platform team, which is the opposite of the leverage you were looking for.

The GitHub issue tracker tells the story clearly. Issue #10004, filed by a company trying to deploy OpenClaw across their org, documents the gaps: no agent-level session filtering, no per-user credential scoping, no shared-vs-personal workspace boundaries. The primitives needed for multi-user deployment don't exist yet, and Steinberger has been clear that building them isn't a priority. That's not what OpenClaw is for.

Is OpenClaw right for you right now?

OpenClaw may work very well for you if:

• Your workflows are already written down
• Your business logic lives in docs or SOPs, not just your head
• You can clearly describe what you want automated
• You're comfortable debugging when things break
• You can dedicate ongoing time to monitoring agents

It's likely to disappoint you if:

• Your processes are mostly implicit
• You want something that works out of the box
• You need multiple people interacting with agents
• You don't want to manage credentials or infrastructure
• You're already stretched thin and hoping this will simplify things on its own

A smart adoption path if you do try it: start read-only. Calendar visibility, email summaries, research briefs. Get value from read access before you hand over the keys to anything destructive.

OpenClaw's security guide explicitly recommends this:

There is no "perfectly secure" setup. The goal is to be deliberate about:

• who can talk to your bot
• where the bot is allowed to act
• what the bot can touch

Start with the smallest access that still works, then widen it as you gain confidence.

Agents don't create clarity, but they do consume it. If your operations are already structured, agents can massively extend your capacity. If your context is scattered, agents will reflect that chaos back at you, faster.

Still want to try OpenClaw? Here's the best resources we've found

If you've read this far and you're still keen to try OpenClaw for yourself, here are some resources we found valuable. We've reviewed a lot of guides out there and these ones actually helped us and our friends.

Start here:

• OpenClaw official getting started guide: the official starting point. Walks you through installation, connecting your AI provider, and linking your first messaging app step by step. If it feels too technical, skip ahead to the walkthrough guides below.
• OpenClaw security docs: read this before you set anything up, not after. Steinberger and the team have been unusually direct about what's risky and why.

Best walkthrough guides:

• OpenClaw Full Tutorial for Beginners by Free Code Camp: a great free end-to-end video tutorial we've found. One hour covering installation, security audits, Docker sandboxing, memory configuration, custom skills, and messaging platform setup. No paywall.
• Master OpenClaw in 30 Minutes by Peter Yang: covers five valuable real use cases (calendar, docs, briefings, reports), Google Workspace setup, and memory/personality configuration. The full guide is only available to Peter's Substack subscribers, but the YouTube video is free and worth watching.
• OpenClaw deployment guide by Digital Ocean: if you want to run it on a VPS instead of a dedicated machine (which we'd recommend considering for security reasons), their 1-click deploy handles firewall rules, non-root execution, and authenticated gateway access out of the box.

On security specifically:

• How to install, set up, and secure OpenClaw on macOS, Linux, and Windows by @bitlaunchio: a good step-by-step for macOS, Linux, and Windows with practical security hardening steps that other guides skip.
• OpenClaw SECURITY.md on GitHub: the project's own vulnerability reporting and security model documentation.
• Run openclaw security audit --deep after setup and actually follow what it tells you. This isn't optional.

On locking things down:

Spend extra time to actually lock things down before you turn anything on.

• Apple Platform Security Guide: if you're running on macOS, this covers FileVault, SIP, Gatekeeper, and firewall + stealth mode (System Settings → Network → Firewall).
• Tailscale: for mesh VPN networking so your agent is reachable without exposing ports to the public internet.
• Look into SSH hardening: disable password auth, key-only. Non-negotiable if you're running on a remote server.
• OpenClaw Discord: where the most practical setup help actually happens. More useful than the docs for troubleshooting.

The best thing you can do right now

I wrote recently about agents being stuck in their command line era. OpenClaw is the best proof of that thesis. Immensely powerful, but only accessible to people willing to work close to the metal.

Whether or not you use Claw today, the single best thing you can do is start building the context that agents need to be useful. Write down your recurring tasks. Document your decisions and the reasoning behind them. Centralize your business knowledge somewhere structured. Define what "good" looks like for your most common workflows. This isn't busywork. It's the raw material that any agent system will eventually consume, and the founders who do this work now will be able to adopt agent tooling faster when it meets them where they are.

We're building Toyo to abstract away everything I've described in this post, the setup, the security, the infrastructure, the memory management, while retaining as much of the power and capability that makes OpenClaw genuinely useful. It's not ready yet, but we'll be launching to beta users soon. If that sounds interesting, you can sign up for early access here.