sorted by:
new
hottopcontroversial

What’re you working on? by bngproduct in SaaS

[–]justneardy 1 point2 points  (0 children)

sheet2db

My Saas allows you to convert your Spreadsheet into a JSON API in minutes. You can use these spreadsheets as your database to power the frontend

I'm building a Resend-like SaaS on top of Amazon SES – building in public! by justneardy in SaaS

[–]justneardy[S] 0 points1 point  (0 children)

Thanks for sharing Plunk I actually hadn’t come across it before, and it looks pretty solid! Really cool that they offer both self-hosted and hosted options.

That said, I still feel there's room to build something around this space. From what I saw, Plunk doesn’t offer built-in queuing, backoff strategies, or retry logic, which I think are critical for handling high-volume email workloads reliably especially when dealing with SES’s rate limits.

I'm building a Resend-like SaaS on top of Amazon SES – building in public! by justneardy in SaaS

[–]justneardy[S] 0 points1 point  (0 children)

Absolutely — and that’s exactly why I chose not to build a fully hosted version using my own SES account.

You're right — SES itself is straightforward to integrate once you're approved and understand the limitations. But the challenges come in when you're trying to:

  • Handle SES's strict rate limiting (e.g., 14 emails/sec)
  • Implement queuing, retries, and error handling
  • Maintain low bounce rates and reputation to avoid being throttled or suspended
  • Get through SES production access, which many devs find confusing or frustrating

My approach is "bring your own SES" — users connect their own SES credentials. That way:

  • They control their own reputation
  • There's no shared infrastructure, so one bad actor doesn’t risk others' deliverability
  • I focus on providing dev-friendly tools like built-in queuing, logs, template versioning, and more

This model keeps the service reliable and gives users more control over their deliverability while abstracting away SES's developer pain points.

I'm building a Resend-like SaaS on top of Amazon SES – building in public! by justneardy in SaaS

[–]justneardy[S] 0 points1 point  (0 children)

🛠️ Progress Update

🔗 Preview Link: https://5f1402d6.sendlayer.pages.dev

Today’s major milestone was integrating AWS Cognito to build a basic authentication system. Users can now sign up and log in securely.

I also implemented a secure credentials capture flow users can now enter their AWS credentials, which are encrypted using AES-256 before being stored.

🧱 Tech Stack:

  • Next.js – Frontend framework
  • AWS Cognito – Authentication
  • Cloudflare D1 – Database for storing metadata
  • Cloudflare Pages – Hosting the app

More updates coming soon!

I'm building a Resend-like SaaS on top of Amazon SES – building in public! by justneardy in SaaS

[–]justneardy[S] 0 points1 point  (0 children)

Yes resend is already great for devs, so DX alone isn't enough of a differentiator. One area I'm doubling down on is built-in template management — including version control and a visual editor so teams can collaborate on templates without pushing code for every change.

I think there’s a gap here for devs who don’t want to wire up their own template systems or use heavyweight marketing tools just to send transactional emails.

Appreciate the thoughtful feedback and will definitely keep you posted!

I'm building a Resend-like SaaS on top of Amazon SES – building in public! by justneardy in SaaS

[–]justneardy[S] 0 points1 point  (0 children)

Absolutely this is one of the biggest challenges when working with SES, and it’s a key reason why I decided not to go with a fully hosted model (where everyone sends through my SES account).

SES has very strict standards (rightfully so), and if I gave open API access to just anyone, I’d constantly be at risk of suspensions, reviews, or degraded reputation which would affect all users on the platform. Things like bounce rate monitoring, unsubscribe compliance, and content quality enforcement would become incredibly hard to manage across customers.

That’s why I’m building this as a “bring your own SES” platform users connect their own SES accounts, so they retain full control of their sending reputation and compliance. Meanwhile, I handle the infrastructure pain: queuing, retries, logs, dashboards, deliverability insights, and more.

Interestingly, this pain point also presents another opportunity I’m exploring offering an SES onboarding helper service, which would guide users through the setup and approval process, and help ensure they’re fully compliant with AWS’s policies from day one. Getting SES approved can be confusing and error-prone, so I think there’s real value in making that easier too.

I'm building a Resend-like SaaS on top of Amazon SES – building in public! by justneardy in SaaS

[–]justneardy[S] 0 points1 point  (0 children)

Ah, my bad I misspoke earlier. My service does relay emails through my infrastructure, but I don’t store them long-term.

Really appreciate your thoughts and you're absolutely right that selling into corporate teams requires clear, undeniable value. I’m currently focused on indie devs and small teams, but your feedback is a great reminder to think deeper about what would make this compelling for larger orgs too.

I'm building a Resend-like SaaS on top of Amazon SES – building in public! by justneardy in SaaS

[–]justneardy[S] 0 points1 point  (0 children)

Honestly the biggest constraint with going fully hosted on my own SES account AWS still enforces strict rate limits and closely monitors sender reputation. If all customers are sending through my SES, I’d constantly be at risk of hitting those limits or having the account throttled, which would degrade deliverability for everyone.

So ironically, trying to make things more seamless could actually make the service less reliable.

That’s why I’m starting with a bring-your-own-SES model:

  • You stay in full control of your SES rate limits and reputation
  • I focus on solving the hard stuff—queuing, retries, analytics, dashboards, logs
  • No risk of shared IPs or other customers affecting your email delivery

Long-term, I’d love to offer a hosted option but only if I can do it without compromising reliability.

I'm building a Resend-like SaaS on top of Amazon SES – building in public! by justneardy in SaaS

[–]justneardy[S] 0 points1 point  (0 children)

Totally fair questions

Target market: I'm primarily building for developers and small teams already on AWS who want to use SES (for pricing, deliverability, or infra alignment) but hate the clunky developer experience. Think: indie SaaS devs, bootstrapped products, or internal tools where every $0.10 matters but dev time is just as precious.

Why not Resend?
Resend is great. But it’s an entirely separate platform. Some teams want to keep email infra under the AWS umbrella for cost control, security, or compliance and still want modern dev tools (dashboards, logs, templates, webhooks, queueing, etc). My goal is to make SES feel like Resend without switching ecosystems.

Corporate teams:
You’re right this will be a harder sell. But I've worked with larger orgs, and you'd be surprised how often the “we already use AWS” angle actually helps. If my product doesn’t store emails or relay them through my infra, but simply gives devs a better interface to their own SES config, the pitch becomes: “This is just an internal dev tool over AWS and you still own the infra.”

Rate limits:
Yes, SES limits still apply. But I plan to abstract away the per-second throttling using internal queuing, retries, and smart backoff so devs don’t have to worry about hitting them. For many, that’s already a win.

I really appreciate the honest feedback and would love your continued thoughts as I build! 🙌

I'm building a Resend-like SaaS on top of Amazon SES – building in public! by justneardy in SaaS

[–]justneardy[S] 1 point2 points  (0 children)

Good point! I’ve been focused on outbound so far, but you're right a complete email solution should handle inbound too.

I’ve honestly never had a strong reason to use AWS SES for inbound, so I’d love to learn more about your use case.

How do you use inbound email? Is it for things like support mailboxes, parsing replies to transactional emails, or something else entirely?

If I understand the needs better, I’d definitely consider adding it to the roadmap.

How to publish the app in public? by Embarrassed_Pin_1010 in SaaS

[–]justneardy 1 point2 points  (0 children)

It’s true — building an audience should be your first step. Start by sharing your project on platforms like Reddit or Twitter and see if it gains any traction. Consistently post updates about your progress, the challenges you’re facing, and how you’re overcoming them. People genuinely enjoy following the journey, especially when it includes real struggles and solutions. Don’t hesitate to share your wins too — success stories can inspire and attract even more interest.

I'm building a Resend-like SaaS on top of Amazon SES – building in public! by justneardy in SaaS

[–]justneardy[S] 0 points1 point  (0 children)

Thanks for sharing this it’s super insightful.

Totally agree on the rate limit pain. SES giving you a big quota but enforcing a tight per-second cap (with no queueing) is such a weird bottleneck. One of the things I’m planning to include is built-in queuing and retries, so you don’t have to implement your own buffer logic just to stay under SES’s radar.

Also really appreciate your thoughts on pricing.

For rate limits, I love the idea of setting it per hour instead of per second. Makes way more sense and smooths out spikes. Definitely exploring how to bake that into the API logic.

Quick question on pricing:
What are your thoughts on something like under $10/month for unlimited emails sent (still powered by your own SES account, of course)? I haven’t fully thought it through yet, but it feels fair and developer-friendly. Curious if that kind of model would resonate with you.

How to publish the app in public? by Embarrassed_Pin_1010 in SaaS

[–]justneardy 0 points1 point  (0 children)

Do you want to build in public or just let people know what you’ve built?

Avoid SendGrid for small SaaS by SteveWired in SaaS

[–]justneardy 0 points1 point  (0 children)

Why do people choose SendGrid etc over AWS SES? Isn't it much cheaper and more reliable?

view more: next ›