How we ship new features · Resend

We ship early

We constantly review the scope of a project and work toward a v0, not a v1.

That means identifying the most crucial part of a functionality , and pushing the smallest pull request possible to make that happen. In fact, a PR should always be optimized for the speed with which we can merge it in.

Shipping to production

Before shipping to production, we think about all the different artifacts that might be affected by a new feature.

Here's a non-exhaustive list of things we ask ourselves:

• Does the API need to be updated?


• Is the OpenAPI spec up to date now?


• Have we released all the official SDKs?


• Do we need to write a Changelog post to announce th

... See more

We ship often

Shipping early is not enough. We also need to keep shipping tiny iterations daily instead of waiting months to ship something big.

Having a strong sense of urgency , and making hard decisions fast is how we enable that process. Our sprints only last 1 week and are quite short when compared to the rest of the industry - this is by desig... See more

Using feature flags

It's always a good idea to put new features behind a feature flag.

This contributes to a rollout strategy that can surface user feedback in a much more contained and safe environment.

When thinking about how to rollout a new feature to users, first think about your peers. Many of the Resend team members also use Resend on their ow... See more