claw.site

claw.site

An app studio for purposeful consumer products.

One team, one platform, many products. Each app lives on its own subdomain with its own brand and its own users — built on shared infrastructure so the work goes into the products and not the plumbing.

What this is

A studio is a place that ships products. claw.site is the place where our products live alongside each other without colliding. Auth, billing, storage, and observability are written once. Everything that is specific to a single product — its landing copy, its onboarding, its AI prompt, its session library, its theme — is data on the shared platform, not a separate codebase. That makes the cost of starting a new product roughly equal to the cost of writing the product itself, which is the only cost that should matter.

A product reaches its users at <product>.claw.site. From the user's point of view it looks like its own site. From the team's point of view it is one deployment with strict per-product data isolation enforced at the database, not at the codebase. We chose that boundary because a shared codebase invites cleanup; a shared database with row-level rules survives it.

How it works

Every request lands on a host classifier. If the host is claw.site you are reading the studio. If the host is <product>.claw.site a server middleware tags the request with the product's identity and passes it on. Every database read carries that identity into a row-level policy that refuses to return another product's data, even with a forged request and a stolen session. The proof of that boundary is a small set of tests we run on every change.

When a new product graduates from idea to launch, it gets a row in the apps table, a theme, an onboarding flow, an AI prompt, a session library, and a price. None of that is code. Two products on the same deployment can disagree about every single one of those choices without either knowing the other exists.

What to read next