When the Claude App Is Enough, and When It Isn’t

How BitSafe Runs, Companion Essay

A custom AI system can be an impressive answer to the wrong question.

If one person needs help drafting, researching, analyzing files, or organizing a project, the Claude app is usually the sensible starting point. It is packaged, maintained, and ready to use. A team can get useful work from it without becoming the operator of another internal system.

That answer has become stronger as the product has changed. As of August 2026, Claude supports shared Projects, project-scoped memory, collaboration, connectors, scheduled work, and organization-level administration. Claude Tag also brings a shared Claude interface into Slack. Availability varies by plan, but any comparison that treats Claude as personal-only, temporary, purely reactive, or impossible to govern is already stale. Anthropic’s Claude Tag announcement Claude scheduled tasks

The build-versus-buy decision has therefore moved. The question is no longer whether a packaged assistant can support shared work. It can. The question is whether your company has a narrow coordination problem that the packaged product does not solve well enough.

Our rule at BitSafe is to buy the product first and build only after the missing layer becomes visible.

The Claude app is enough when the work is mainly conversational or artifact-based.

That includes researching a topic, reviewing a document, preparing an analysis, drafting a memo, or working through a set of files with a small group. Projects can hold shared source material. Memory can preserve useful context. Connectors extend the work into other services. Scheduled tasks cover many recurring research and reporting needs.

The product also removes a long list of responsibilities. Anthropic maintains the interface, model access, collaboration features, security controls, and product updates. Administrators can manage use without designing an internal orchestration layer from scratch.

That maintenance transfer matters. Every custom component creates a future decision about reliability, permissions, cost, and ownership. A feature that seems small during a prototype can become a permanent operating obligation.

A company should not accept that obligation to prove it can build with AI.

Use the packaged product until the work itself shows a persistent gap. A one-off inconvenience is not a platform requirement. A repeated coordination failure might be.

We built NanoClaw after the bottleneck moved beyond individual assistance.

The model was not the reason. NanoClaw runs on Claude. We did not build a smarter brain. We built a company-specific execution layer around the same model family.

The need appeared in work that crossed several systems, required bespoke computation, or had to update shared operational state. A useful result might depend on a current workspace record, a recent conversation, live external data, and a calculation that did not fit a standard connector. The output then had to return to the right system of record with a traceable owner.

That is different from asking an assistant to produce a document. It is a coordination problem.

Four conditions can justify a custom layer.

A packaged assistant can retrieve from connected sources. A custom system becomes relevant when the task needs company-specific joins, rules, or calculations across those sources.

The distinction is not access versus no access. It is retrieval versus a maintained method. If a result depends on matching entities across systems, applying local business logic, or producing a repeatable calculation, code may be the clearer control surface.

Some work ends with an artifact. Other work ends with a state change.

A task may need to update an approved record, open a defined workflow, or run a specialized external process. When those actions require local rules, bespoke tools, or deterministic checks, a custom execution layer can earn its place.

Memory is useful, but company state needs explicit ownership.

A project status, approval, customer record, or policy should live in a system that the relevant people can inspect and maintain. At BitSafe, Notion holds that collaborative state. NanoClaw reads it when needed and returns durable results to it.

We do not treat a model’s memory as the sole authority for business facts. Memory can support continuity. The system of record remains accountable.

A company may need a narrower permission model, a specific audit trail, a deterministic guard, or an integration that the packaged product does not provide.

This is the strongest reason to build, and it should be stated precisely. “We need more control” is too vague. The team should be able to name the missing control, explain the risk it addresses, and define who will maintain it.

A custom layer does not require replacing the packaged product.

The two can coexist. People can use Claude for analysis and drafting while the custom system handles the small set of workflows that require bespoke computation or execution. This keeps the custom surface narrow and lets the vendor absorb the general-purpose work.

We review that boundary regularly. When a packaged feature becomes good enough, the rational response is to retire the duplicate or reduce its scope. The code already written is not a reason to keep operating it.

That discipline protects a team from turning infrastructure into identity. The purpose of an internal AI stack is to improve work, not to preserve its own complexity.

Before building, ask five questions.

If the first answer is yes, stop there.

If the gap is recurring and company-specific, prototype the smallest layer that closes it. Keep the source of truth outside the model. Define how the work is observed and how the component can be removed later.

The honest case for custom AI begins after the packaged product has been given a fair chance.

For most people, Claude is enough. For many teams, Claude with its collaboration and scheduling features is also enough. Build when coordination becomes the bottleneck and when you can name the missing layer without resorting to a catalogue of features.

That is a smaller claim than “every company needs an AI operating system.” It is also a more useful one.

Subscribe to the BitSafe newsletter for more field notes on how we run the company.