---
title: How we ship new features
slug: how-we-ship-new-features
description: "Our strategy for putting software in the hands of users."
humans: ["zeno-rocha"]
updated_at: "2025-03-12"
created_at: "2024-06-04"
---

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

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](https://vercel.com/docs/deployments/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 a unique URL pointing to our Staging environment that allows us to perform extra tests even before merging the code.

## Using feature flags

We often put new features behind a feature flag to help us [separate code deployments from feature releases](/handbook/engineering/how-we-separate-deployments-from-releases).

We use [Posthog](https://posthog.com/feature-flags) 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.