Not every person lives in San Francisco.
Not every engineer has the same skill level.
Not every team uses the hottest framework.
We can't build something only for the wealthy users but also for users at the margins (think the 90th percentile) who may not be on the fastest computers, wifi networks, or have access to the latest tech.
That's why we have a generous free tier.
That's why we have SDKs for all languages.
That's why we have docs for beginners.
That's why it must be fast.
We only have one chance to make a first impression, so the onboarding experience should be flawless.
It can't ask for a credit card.
It can't have dozens of steps.
It can't require a "demo" or "call".
It can't be a two-day verification process.
If a developer's first attempt at using the product takes several hours, they won't be coming back.
They should be able to go from hello world to production in minutes.
Most companies treat documentation as an afterthought, something you do later.
For us, documentation is not auxiliary to the product.
Documentation is the product.
It's one of the first things developers will interact with when they're learning, and it's the thing they'll keep coming back to as they integrate deeper.
This means we need to treat it as a first-class citizen. It needs CI/CD, it needs to be in-app, it needs to be up-to-date, and it needs a roadmap.
Uptime is as essential for infrastructure as water is essential for life.
We can have the most beautiful product in the world, but if it's not online, then it's all for nothing.
Reliability is the foundation of everything we do, and every time there's a downtime, we lose trust.
At the end of the day, we're providing infrastructure, just like water, energy, and transportation. Would you drink water that is only treated 99% of the time?
The output of the product should be credible, consistent, and predictable.
Our platform is used by thousands of people in thousands of different ways. So, we must respect the contracts and interfaces we have with users. Updates should not result in surprises.
The response objects shouldn't change without notice. The error codes should follow the same structure. The API should be backwards compatible.
When you load a page, when you visit the dashboard, when you make an API call, it can't be slow.
We need to always be decreasing response times, and improving performance. We should be constantly asking ourselves, "How can we make this faster?"
When in doubt, do what's faster for the user even if it means making it harder for us to build, test, and maintain.
For Resend to make an impact, it can't be just a little bit better than what's available out there. It needs to be an order of magnitude better.
The way to do that is by obsessing over every detail no matter how small. We believe that the sum of all the small details is what makes something special.
That's why we're willing to spend more time on something that may not be noticed by most people but will be truly appreciated by the right people.
