How we ship new features

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.

It's vital that we put new things in the hands of users as soon as possible. Building in a silo is not a great idea, and we can only learn when real people are using a feature in a real-world scenario.

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 design.

Engineers respect teams that are “always shipping”, and we believe that great things are built one brick at a time.

We ship together

It's very common for a feature to be started by one person and finished by another.

Sometimes, someone will work on the first 80%, and then someone else will push the last 20% to the finish line.

This is a great way to share knowledge and make sure that everyone is familiar with the codebase.

Using preview deployments

For our dashboard and public website, we use Preview Deployments from Vercel.

Having a unique URL for each PR we open is vital. They are great not only for getting feedback internally but also for gathering opinions externally from peers who work at different companies. Fun fact: the preview URL of this handbook itself was shared externally with many of our friends before it was merged into production.

For our API, we also get an unique URL pointing to our Staging environment that allows us to perform extra tests even before merging the code.

Using feature flags

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

We use Posthog for that, which 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 own side projects. So asking feedback internally is an amazing way to improve the quality of a feature before a wide rollout.

Before releasing to all users, reach out to those who asked for that particular feature in the past. Every time a new feature request comes in, we register who asked for it. Closing that feedback loop is one of our favorite things.

Reminder: feature flags are great, but not every feature needs it too.

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 this?
• Is there any existing Documentation that needs to be updated?
• Do we need to write a new Knowledge Base article to go along with this?
• How does this change affect our Support team?

Every new feature is a chance to make the life of our users better. We take that very seriously.