send.dev — Product Requirements Document

Business Case & Product Overview

Version: 1.0
Last Updated: December 2024
Status: Planning

Executive Summary

send.dev is a developer-first communications platform that provides simple, reliable APIs for sending emails, SMS, and physical mail. We're building the infrastructure layer that lets developers stop worrying about deliverability, compliance, and scaling—and focus on their products.

The premium domain (send.dev) positions us as the obvious choice for developers who want to "send things" programmatically.

Problem Statement

The Developer Pain

Developers building applications that send communications face a fragmented, frustrating landscape:

1. Email is deceptively complex

   • Setting up proper authentication (SPF, DKIM, DMARC) is confusing
   • Deliverability is a black box—emails silently land in spam
   • Managing reputation across multiple sending domains is tedious
   • Existing providers either target enterprise (complex, expensive) or are developer-hostile (legacy APIs, poor docs)

2. Multi-channel is harder

   • Adding SMS means a completely different provider, SDK, and mental model
   • Print/mail is even more obscure—most developers don't know where to start
   • No unified view of all customer communications

3. Scaling brings new problems

   • Sudden volume spikes get accounts suspended
   • Compliance requirements (opt-outs, suppression lists) are easy to get wrong
   • Debugging delivery issues requires stitching together multiple dashboards

Who Feels This Pain Most

• Startups and scale-ups building SaaS products with transactional email needs
• Developers at companies using legacy ESPs who want modern tooling
• Product teams adding notifications, alerts, or marketing communications
• Agencies building client applications that need reliable sending

Market Opportunity

Total Addressable Market

Competitive Landscape

Our Position

We sit between "raw infrastructure" (SES) and "full-service ESP" (SendGrid). We provide:

• The simplicity and DX of Postmark/Resend
• The pricing efficiency of building on AWS
• The multi-channel ambition of Twilio (without the complexity)

Differentiators:

1. Premium domain — send.dev is memorable, brandable, developer-native
2. Multi-channel from day one — unified API design for email → SMS → print
3. Transparent infrastructure — we tell you exactly how we send (AWS SES) with no lock-in
4. Modern DX — TypeScript SDK, excellent docs, webhooks that actually work

Product Vision

Mission Statement

Make sending communications as simple as a single API call, regardless of channel.

Product Principles

1. Developer-first, always — If a developer can't integrate in 5 minutes, we've failed
2. Transparent by default — Show delivery status, costs, and issues clearly
3. Progressively powerful — Simple things simple, complex things possible
4. Reliable above all — Emails must arrive. Everything else is secondary.

Long-term Vision

Year 1: Best-in-class transactional email for developers
Year 2: Unified communications platform (email + SMS + print)
Year 3: Intelligent routing, templates, and automation layer

Target Users

Primary Persona: "Dev Dave"

Role: Full-stack developer at a Series A startup
Context: Building a B2B SaaS product, needs transactional email
Goals:

• Ship features fast without becoming an email expert
• Reliable delivery without babysitting
• Clear pricing that scales predictably

Pain points:

• Spent 2 days debugging why emails went to spam
• SendGrid's pricing jumped unexpectedly after a product launch
• Can't get visibility into why certain emails bounce

Quote: "I just want to call an API and know the email will arrive. Is that too much to ask?"

Secondary Persona: "Platform Patricia"

Role: Platform/Infrastructure engineer at a mid-size company
Context: Managing email infrastructure for multiple products/teams
Goals:

• Centralized control over sending domains and reputation
• Usage visibility and cost allocation by team
• Compliance and audit capabilities

Pain points:

• Different teams using different providers
• No unified view of sending reputation
• Hard to enforce best practices across the org

Tertiary Persona: "Agency Alex"

Role: Technical lead at a development agency
Context: Building applications for multiple clients
Goals:

• Quick setup for each new client project
• White-label or client-branded sending
• Simple billing separation per client

Feature Requirements

Phase 1: Email (MVP)

Must Have (P0)

Should Have (P1)

Nice to Have (P2)

Phase 2: SMS

Phase 3: Print

User Journeys

Journey 1: First Email Sent

1. Developer lands on send.dev
2. Signs up with GitHub (one click)
3. Sees dashboard with API key already generated
4. Copies curl example, runs it
5. Receives test email in their inbox
6. ✅ Time to first email: < 2 minutes

Journey 2: Production Setup

1. Developer adds their domain (e.g., notifications.acme.com)
2. Dashboard shows required DNS records (SPF, DKIM, DMARC)
3. Developer adds records to their DNS provider
4. send.dev detects and verifies automatically
5. Developer updates their app to use verified domain
6. ✅ Time to production: < 30 minutes

Journey 3: Debugging a Delivery Issue

1. Customer reports they didn't receive an email
2. Developer searches by recipient email in dashboard
3. Sees the specific message, its status, and timeline
4. Identifies: email bounced due to invalid address
5. Views bounce reason and suggested action
6. ✅ Time to resolution: < 5 minutes

Success Metrics

North Star Metric

Monthly emails delivered successfully — This captures both growth (more customers sending more) and quality (high deliverability).

Primary Metrics

Secondary Metrics

Business Metrics

Pricing Strategy

Philosophy

• Generous free tier to reduce friction and drive adoption
• Simple, predictable pricing that scales linearly
• No gotchas — what you see is what you pay

Proposed Tiers

Overage Pricing

• Email: $1.00 per 1,000 emails over plan limit
• SMS: $0.01 per segment (US), international varies
• Print: Starting at $0.75 per letter (US)

Competitive Comparison

Go-to-Market Strategy

Launch Phases

Phase 0: Private Alpha (Month 1-2)

• 20-50 hand-picked developers from network
• Focus: API design validation, find critical bugs
• Feedback: Weekly calls, Slack channel

Phase 1: Public Beta (Month 3-4)

• Open signups, free tier only
• Focus: Onboarding flow, documentation, reliability
• Marketing: Twitter/X, Hacker News, dev communities

Phase 2: General Availability (Month 5+)

• Paid tiers available
• Focus: Growth, support infrastructure, enterprise features
• Marketing: Content marketing, case studies, partnerships

Marketing Channels

Key Messages

1. "Send anything, anywhere, with one API" — Multi-channel vision
2. "Emails that actually arrive" — Deliverability focus
3. "Five minutes to your first email" — Speed of integration
4. "Built on AWS, priced fairly" — Transparency

Technical Requirements

Performance

Scale

Security

• SOC 2 Type II compliance (Year 1 goal)
• Data encryption at rest and in transit
• API key hashing (keys never stored in plain text)
• Audit logging for all administrative actions
• GDPR-compliant data handling

Compliance

• CAN-SPAM compliance features (unsubscribe handling)
• GDPR data export and deletion capabilities
• Automatic suppression list management
• Bounce and complaint handling per ESP requirements

Risks & Mitigations

Dependencies & Assumptions

Dependencies

• AWS SES production access approval
• Cloudflare Workers/D1/R2 reliability
• Domain DNS propagation (customer side)
• Third-party integrations (Stripe)

Assumptions

• Developers prefer API-first over UI-heavy solutions
• Transparent pricing is a meaningful differentiator
• Multi-channel (email + SMS + print) is valuable, not confusing
• The "send.dev" domain provides meaningful brand value

Open Questions

1. Free tier limits — Is 1,000 emails/month enough to be useful without being abused?

2. Template system — Build custom or integrate with existing (React Email, MJML)?

3. Inbound email — How important is receiving emails for MVP?

4. Self-serve enterprise — Can we offer dedicated IPs without sales involvement?

5. Print partner — Lob vs. alternatives for cost and coverage?

Appendix

Competitive Feature Matrix

Reference Links

• AWS SES Best Practices
• Email Authentication (SPF/DKIM/DMARC)
• Cloudflare Workers Documentation

Document History