I built a Resend alternative from Serbia — waitlist is open, looking for first feedback
I got tired of Resend pulling the rug on pricing.
In October 2024 they doubled prices overnight. No warning, no email — just a doubled invoice. I was building AI apps and every single one needed transactional email. That was the moment I decided to build my own.
So I started PrimeTimeMail — a transactional email API for developers. Same AWS SES infrastructure under the hood. Simpler API. 40% cheaper than Resend.
One promise I'm making that nobody else does: prices are locked for 12 months when you sign up. You won't wake up to a doubled invoice.
Where I'm at right now:
Landing page is live
Backend is running locally (register, API key auth, send, list emails — all working)
AWS SES production access pending
Waitlist is empty and I need first humans to tell me if this is useful
If you've ever been burned by an email provider — I'd love to hear about it. And if this sounds useful, the waitlist is open: https://primetimemail.com
Not asking you to pay anything. Just asking: would you use this?
Be careful making price the wedge in transactional email. The giants sit on top of AWS SES, which is close to free at the infra layer, so anyone can undercut you, and a price war is a race the small player does not win. Worse, a price lock attracts the most price-sensitive, churny customers, the ones who leave the day a competitor runs a promo. The real moat in email is deliverability and support, not cents per thousand. Resend won on developer experience, Postmark won on deliverability and human support, almost nobody won on being cheapest. If I were you I would lean hard on the one thing the US giants cannot easily copy: you are EU-based. Data residency and GDPR are a real, painful reason for European companies to not want a US email provider, and that is a wedge price can never be. So who is the specific buyer that switches to you first, and is it because of your price, or because of where your servers live?
This is the most useful pushback I've gotten. You're right that price alone attracts churny customers — noted.
The EU angle is something I've underplayed. SES eu-north-1 (Stockholm) is the actual infrastructure, data stays in Europe. For a European SaaS sending to European users, that's a compliance argument, not a price argument.
Repositioning that as the primary wedge makes more sense than competing on cents. Thanks for the reframe.
the resend price-doubling thing is exactly why i keep a backup provider configured now, got burned by a similar overnight change. so genuinely interested in this.
honest question for any SES wrapper though, deliverability and support are what people actually pay for, not the API. 40% cheaper is great right up until an email lands in spam and there's nobody to escalate to. so what's your deliverability story, and who picks up when a sending domain gets flagged? nail that and "cheaper resend" turns into "the one that won't rug me".
Honest answer: deliverability is AWS SES infrastructure — same IP pools that power Notion, Reddit, and others. Support right now is founder-direct, which means faster response than a ticket queue, but without a 24/7 NOC. That's the honest tradeoff at this stage. If a sending domain gets flagged, I'm personally on it. Not the right fit for someone sending millions of emails — but for a developer who wants a human who actually picks up, it works.
looks like your reply came through blank on my end, indie hackers does that sometimes. still genuinely curious about the deliverability piece, mainly whether you're on shared SES pools or dedicated IPs, and what actually happens when a customer's domain gets flagged. if it helps, i'm happy to join the waitlist and be a guinea pig with real sending volume.
Hey, thanks for the interest! To answer your questions:
Currently sending via Resend's infrastructure (shared pools), so deliverability is tied to their reputation. Dedicated IPs are on the roadmap for Scale plan users.
When a customer's domain gets flagged — bounce rate auto-monitor kicks in at 3% and pauses sending automatically to protect the sender score.
Would love to have you as a guinea pig with real volume — sign up free at primetimemail.com, no card needed.
The pricing lock promise is the smartest move here — that's the exact pain point that makes developers distrust email providers. Resend's overnight double was a wake-up call for a lot of us.
One question: what happens after the 12 months? Knowing the renewal policy upfront would remove the last bit of hesitation for me
After 12 months, you get a renewal offer at the same or lower price — never higher. If we do raise prices, existing customers keep their current rate for another 12 months before any change applies. No surprises.
This is a clear wedge because transactional email is one of those tools developers only think about when pricing, deliverability, or API friction suddenly becomes painful. The 12-month price-lock angle is actually the strongest part because it gives people a simple reason to try a new provider instead of just comparing you feature-by-feature against Resend.
The thing I’d pressure-test early is the product name. PrimeTimeMail explains email, but it also keeps the product boxed inside “mail provider” language. If the roadmap ever expands into logs, templates, routing, webhooks, alerts, deliverability insights, or developer messaging workflows, the name may start feeling more narrow than the infrastructure layer you are building.
Before waitlist users, docs, API keys, and developer memory build around the current name, I’d think through whether you want a broader developer-platform brand.
Xevoa .com would fit that direction better because it can carry transactional email today, but still leaves room for messaging workflows, developer APIs, alerts, and automation without sounding limited to mail only.
Appreciate you coming back with more detail. The platform direction makes sense and the naming concern is noted — I'll revisit it before docs and API keys lock the brand in. For now, shipping is the priority.
That is the right priority. I would not slow shipping down for a long branding exercise.
The only reason I’d pressure-test it now is because developer infrastructure names get harder to change once docs, API keys, examples, waitlist emails, and early integrations start forming around them.
PrimeTimeMail is clear for the first wedge: transactional email with predictable pricing. But if the product becomes a broader developer messaging layer, the name may keep pulling people back to “email provider” even when the platform is moving into routing, logs, alerts, templates, webhooks, and workflow automation.
That is why Xevoa.com feels worth comparing before those surfaces lock in. It gives you a cleaner platform shell without fighting the current product direction.
So I agree: ship first. I’d just make the name call before the first serious developer-facing assets become expensive to unwind.
Fair point on the naming ceiling — noted for when the platform expands. For now, shipping beats renaming. Will revisit before docs and API keys lock it in.
That is fair. Shipping should stay the priority.
I’d just separate shipping from the name decision. You do not need to do a full rebrand exercise now, but if the product is likely to move beyond transactional email into a broader developer messaging layer, the cleanest time to secure the right platform name is before docs, API examples, waitlist emails, and early integrations start creating memory around PrimeTimeMail.
That is why I brought up Xevoa.com specifically. It feels broad enough for email today, but also strong enough for routing, logs, alerts, webhooks, templates, and workflow automation later.
So I would not slow down launch. But if Xevoa feels like a serious candidate for the platform direction, I would look at it before the developer-facing assets become harder to unwind.
Appreciate the persistence. PrimeTimeMail stays for now — first customer will tell me more than any naming exercise.
That makes sense.
If the first customer is the priority, I would stay focused there and avoid letting naming slow the launch down.
The only thing I’d keep an eye on is whether early users remember PrimeTimeMail as a pricing-led transactional email tool or as something broader. That signal will tell you more than theory.
Good luck with the first customers.
Update #2 — From waitlist to live product
When I posted here 2 weeks ago, PrimeTimeMail was just a landing page and an idea. Today it's a real product.
Here's what I shipped:
→ REST API for sending transactional emails (live, powered by Resend)
→ User dashboard with email logs, API key management, and domain verification
→ Custom domain support (add your domain, get DNS records, verify)
→ Admin panel with maintenance mode toggle, user management, and MRR tracking
→ Legal docs (Terms, Privacy, Refund Policy) — needed for billing
→ api.primetimemail.com live on Railway + PostgreSQL
The stack: Node.js + Express + TypeScript + Prisma + PostgreSQL + Railway
What's next: Paddle billing integration (Phase 4). Once that's done, I'll invite the waitlist.
Honest reflection: I almost gave up during the Railway deploy phase. The build kept failing for different reasons every time — package.json syntax, missing migrations, permission errors on binaries. Took 15+ attempts. But that's the job.
If you're building an email infrastructure alternative and want to follow the journey — I'm posting updates here and on Twitter @mixondev.
Waitlist is still open: primetimemail.com