Principles

The four rules every Zap Studio package follows, the problems they answer, and where Zap Studio stops.

Fourteen packages, one set of rules. This page says what those rules are, so you can predict how a package you have not read yet will behave.

The Problem

Most teams solve these problems by hand, per project — and the hard parts get skipped:

• Fragile by default. Hand-rolled retries and webhook checks quietly skip the parts that matter: jitter, cancellation, constant-time signature comparison.
• Scattered, not audited. Permission checks end up copy-pasted across the codebase instead of living in one place you can read in one sitting.
• Node-only, until it isn’t. Homegrown wrappers break the moment your code runs on an edge runtime or in the browser.

What Every Package Guarantees

• Type safety. Types come from your schema through Standard Schema, not from hand-written annotations. No as casts to make a response fit.
• Framework-agnostic. Built on standard runtime APIs — fetch, Request/Response, AbortSignal, crypto.subtle. No framework adapter, no plugin system, no global setup.
• Composable. Each package does one thing and accepts the others as plain values: wrap a fetch call in a retry policy, validate a webhook payload with validation, pass a logger to any of them.
• Tree-shakeable. Standalone functions with no shared state, one subpath per feature. What you do not import does not ship.

What That Rules Out

These follow from the four rules above, and they are choices, not omissions:

• No runtime of its own. No effect system, no scheduler, no dependency injection container. Functions in, values out.
• No hidden state. Nothing registers a global, patches a prototype, or reads an implicit context. A cache, a policy or a router is a value you created and can throw away.
• No required logging or tracing. Both are optional parameters. Pass nothing and there is no dependency and no cost.
• No CommonJS. Standard ESM only, so the tree-shaking guarantee holds.

Compared to Effect

If you know Effect: yes, there is overlap — typed errors, retries, schema validation. Effect is a full ecosystem built around its own runtime, and that investment pays off once you need that level of control.

Zap Studio stays in plain TypeScript — no new runtime, no new mental model, small packages you adopt one at a time. Reach for it when you don’t need everything Effect brings.

Not For You If

• You want one framework that owns your whole effect/error model — Effect is built for that.
• You need every package to come from a single all-in-one SDK.
• What you have today isn’t costing you bugs.

Next