A pattern is reshaping SaaS pricing and architecture in 2025-2026: bring-your-own-keys (BYO).
Instead of bundling third-party services (email, SMS, storage, AI inference), the SaaS asks customers to connect their own provider accounts. The customer pays the provider directly; the SaaS doesn’t mark up.
This started in developer tools (Vercel, Supabase use this for AI features) and is spreading to operational SaaS — including booking software.
How it changes the customer experience
Traditional SaaS pricing:
- Booking platform: $50/month
- Includes: 1,000 emails, 200 SMS, 5GB storage
- Overages: $0.05 per email, $0.10 per SMS, $0.50 per GB
BYO SaaS pricing:
- Booking platform: $10/month or $100/year
- You connect: SendGrid ($15/month), Twilio ($5/month), S3 ($1/month)
- No overages from the SaaS
For low-volume customers, traditional looks cheaper. For mid-to-high-volume customers, BYO is dramatically cheaper because you’re paying provider cost, not SaaS-marked-up cost.
How it changes SaaS economics
Traditional SaaS:
- Bundle providers, mark up
- Revenue scales with customer activity (more emails = more revenue)
- Margin pressure from provider price increases
BYO SaaS:
- Don’t bundle providers
- Revenue is flat per tenant
- No provider-cost exposure
- Lower COGS per tenant (no email/SMS spend)
For SaaS builders, BYO removes a major source of operational cost variability. The trade-off: lower revenue per customer.
Which SaaS categories are adopting BYO
Heavy adoption:
- AI tools (BYO OpenAI / Anthropic keys — most AI wrappers do this)
- Newsletter platforms (BYO email, increasingly common)
- Booking platforms (Zedule, increasingly others)
- Form builders (BYO email for notifications)
Medium adoption:
- CRM tools (some BYO email, most still bundle)
- E-commerce (BYO payments via Stripe Connect, but most still markup payment processing)
Low adoption:
- Marketing automation (most still bundle)
- Helpdesk SaaS (most bundle email)
- Most enterprise SaaS
Why customers like BYO
- Cost transparency. You see what each component costs. No mystery markups.
- Provider quality. You can pick the best provider for your needs (Postmark for deliverability, Resend for UX, AWS SES for cost).
- Brand control. Emails come from your domain, SMS from your phone number. Customers don’t see the SaaS’s branding.
- Vendor lock-in reduction. Your customer email list is in your ESP, not the SaaS’s database.
- Compliance. Easier to meet GDPR / HIPAA when you control where data flows.
Why some customers dislike BYO
- Setup complexity. Connecting 3-4 providers takes 30-60 minutes of one-time work.
- More accounts to manage. Bills from multiple vendors instead of one.
- Trouble-shooting harder. If something breaks, could be your SaaS or could be your email provider.
For technical or operationally-savvy customers, BYO is a feature. For non-technical customers, it can feel like work.
How SaaS handles the BYO trade-off
Three patterns:
Pure BYO — every external service requires customer credentials. Lowest SaaS price, highest setup complexity.
Hybrid — defaults provided, BYO optional. Easy onboarding, opt-in for power users.
Bundled — SaaS handles all provider relationships. Highest SaaS price, easiest onboarding.
Each works for different segments.
Architecture implications for SaaS builders
If you’re building BYO SaaS, key architectural choices:
Credential storage
Customer’s API keys must be stored securely:
- Encrypted at rest (separate key per tenant)
- Never logged or sent to telemetry
- Accessible only to the runtime that uses them
- Rotation support (customers can update keys)
Provider abstraction
Code shouldn’t be hard-coded to one provider. An email-sending interface that supports SendGrid, Postmark, Resend, SES via adapters means customers can switch.
Failure handling
When a customer’s provider key fails (expired, rate-limited, blocked), the SaaS has to:
- Surface the error clearly
- Not retry indefinitely
- Optionally fall back to platform email if configured
Audit / observability
Customers should see:
- Which emails / SMS were sent
- Which provider was used
- Delivery status
- Failures with reason
But the SaaS shouldn’t see customer-private data (email content, recipient details beyond what’s needed for the booking).
How Zedule does it
Zedule’s BYO model:
Email:
- Connect any SMTP-compatible provider (SendGrid, Postmark, Resend, AWS SES, custom)
- API keys encrypted per-tenant in Cloudflare
- Sender domain configured per business
- Templates editable in dashboard
- Failures surfaced with clear errors
SMS:
- Connect Twilio, MessageBird, Vonage, Plivo, AWS SNS
- Per-event toggles (you can disable any reminder type)
- Failures surfaced
- Cost transparency (Zedule shows what your provider charges per message)
No bundled credits, no markup, no rate limits.
When BYO might be wrong for your SaaS
BYO doesn’t fit every SaaS:
- Free / freemium tier expectations. Customers on free tier won’t set up an email provider.
- Very low-volume use cases. Setup overhead dominates.
- Compliance-sensitive business. Some markets prefer SaaS that takes responsibility for delivery.
- Embedded / B2B2C. Where the end customer is someone else’s customer, BYO is awkward.
For booking software targeting service businesses, BYO has been a strong fit because operators value brand control and cost transparency.
Where this is going
Expect BYO to spread to:
- Storage (BYO S3 / R2 / Backblaze in more SaaS)
- Authentication (BYO OAuth providers, BYO IdP)
- Payments (BYO Stripe / Razorpay / Square account)
- Logging / analytics (BYO PostHog, BYO Datadog)
The pattern works. Customers like it. SaaS builders like the unit economics. The trade-off is onboarding complexity, which is being smoothed over with better tooling.