How We Ship.

The path to production

There is no separate release step to schedule or a train to catch. Merging is the release. That's what makes small PRs the right unit of work — each one is independently shippable and independently reversible.

What CI checks

One pipeline runs on every pull request (drafts are skipped). It builds, lints, type-checks, and tests the packages your change touches, using a shared remote cache so it only does the work that's actually needed. Two things are worth knowing:

• An inline review bot posts lint and type findings directly on the diff. Running the same checks locally first keeps your PR clean.
• Generated code is gated. Our shared types are generated from a source of truth; a dedicated check fails the build if the committed output has drifted. Regenerate and commit if it does.

CI is the gate, so review can stay focused on whether the change is right rather than whether it's formatted.

Per-surface deploys

Each part of the system deploys independently, so a frontend change doesn't wait on a backend change. A merge only redeploys the surfaces it actually affects.

How we think about speed

Deployment speed isn't about racing — it's about keeping the distance between "I wrote it" and "it's live" short enough that problems are small and obvious. A few habits follow from that:

• Small PRs over big ones. A change you can review in five minutes is a change you can roll forward or back in five minutes.
• Merge behind the change when you're behind main. Long-lived branches drift and break in confusing ways; keep them short.
• Make changes reversible. Prefer additive, independently-deployable steps over big-bang cutovers.
• Trust the gate. If CI is green and review passed, ship — don't sit on a change waiting for a "better time."

Bugs & hotfixes

Because deploys are fast and small, our default response to a bug is to fix forward — a focused follow-up PR through the normal pipeline — rather than a heavy rollback. A hotfix isn't a different process; it's the same process with a smaller diff and a faster review.

1. Confirm and locate. Reproduce, then use logs and error reporting to pin down the cause (see Runbooks for reading production logs).
2. Make the smallest fix. Resist the urge to refactor around it — a bug fix is not a cleanup PR.
3. Lock it with a test when the bug could recur, so the same regression can't ship twice (see Testing).
4. Ship it through the normal flow. If it's urgent, the small diff makes for a fast review.