Stacked PRs

Approach learned from an internal August 2026 Supabase Slack thread by Ivan Vasilov.

The point is to de-risk shipping. Each PR in the stack must be mergeable on its own. Do not stack only to make review chunks smaller.

How to split

When it makes sense, go code first:

1. Queries, hooks, and package changes
2. Components
3. Tests

An alternative, when it makes sense, is shipping features one by one. Smallest feature first, then more, then more. Ask if you are unsure which split is safer.

Do not put an unusable half-feature on main. "Mergeable on its own" means the product still works if later PRs never land.

Two valid shapes