Why Every Indie Hacker I Know Is Overpaying for Email
I've been talking to a lot of indie hackers about their email setup lately, and I keep noticing the same thing: most of us are overpaying, not because we send too many emails, but because our contact list grew.
Most ESPs charge based on contacts stored. So when your Product Hunt launch brings in 3,000 new signups overnight, your email bill jumps before you've even decided what to send them. You're paying for people sitting in a database.
I wrote about why this pricing model is broken for indie hackers and what the alternative looks like.
Curious if others have run into this. What are you using for email right now, and how much are you paying?
Trending on Indie Hackers
Interesting take. We are indeed spending quite a bit on email, and we've had to switch providers a few times due to pricing changes.
One challenge we keep running into is that most email providers are US-based, which complicates things for an EU company, especially since both the email content and recipient data pass through the provider
I've been having the same issues. Currently using Sweego as it's in EU and a newcomer with a fairly generous free plan and for up to 20k monthly emails it's still quite inexpensive. Although all providers seem to get more expensive over time as you mentioned... I initially integrated emails to my app directly via a provider's API, but then moved on to having the provider specified by configuration only and using SMTP for sending instead of API integration to be able to easily swap out the providers.
Even later I started using Apprise. It's got a BSD-2-Clause license and can run from a (small) docker container or I think it can also be directly integrated as a library, if using Python. Basically it's like a library/API that manages different integrations - a bit like Zapier. I think there's a company behind it too that provides a hosted version, but I've not used their services myself.
Anyway, I started using it more because I also wanted to integrate my notifications with other services beyond email such as Slack, Telegram and others, but I think would have been better off using it from the start as it's so easy to replace an email provider or use other integrations through it. It's way more standardized than I could maintain myself. Maybe useful for others here too when building something that needs to send a lot of notifications.
This should be a solvable problem I assume. Are there any specific challenges?
The main issue tends to be compliance and data residency. When the provider is US-based, both the email content and recipient data can technically be transferred outside the EU, which raises GDPR concerns. Even if providers rely on mechanisms like the EU-US Data Privacy Framework or standard contractual clauses, some companies (us for instance) still prefer to avoid the legal uncertainty or extra compliance work.
There are a few EU-hosted providers, but the ecosystem is smaller and pricing/features often differ from the big US email platforms, so teams end up balancing compliance comfort vs. tooling and cost.
I’ve noticed something similar with email tooling.
A lot of founders start with powerful platforms designed for marketing teams, while early-stage products often only need a few behavioral triggers and simple sequences.
The tooling becomes overkill long before the product actually needs it.
Out of curiosity — what stack would you consider the “lean” setup for an early-stage SaaS today?
Do checkout AutoSend.com - a $12 /m plan is more than sufficient for 80% of indie hacker.
PS: that 80% is just to show the majority :D
You can also explore keplars.com - 5$/m plan to start with a custom domain, and also if you don't have custom domains yet for for free plan which uses OAuth emails where you get the option to edit your sender name to your brand as well. Worth checking it out.
Interesting — thanks for sharing that.
A lot of founders seem to move toward simpler email stacks early on before they actually need heavy marketing automation.
What kind of use case does AutoSend work best for in your experience — transactional emails or onboarding sequences?
For both - that's the best part. The biggest benefit of using single provider for both is that transactional emails actually help you build a good sender reputation which get's shared with your marketing emails as well.
PS: if you use same doamin for sending transactional and marketing emails both.
That’s a good point.
The shared sender reputation aspect is often overlooked.
A lot of people treat transactional and marketing emails as completely separate systems, but consolidating them can simplify deliverability management quite a bit.
Have you seen this make a noticeable difference for smaller senders as well, or mostly at larger volumes?
I so agree to this!
This is actually a big pain, especially after a launch spike.
I ran into the same thing.
I ended up trying Keplars recently and it worked pretty well for my use case. what i liked was you can just start with OAuth (gmail/outlook) without dealing with domain setup upfront, which saved a lot of time early on.
then, i moved to their custom domain plan basically 5$ to start with, their entry plan is pretty cheap compared to most tools and deliverability has been solid so far (no weird issues), and you also get proper visibility into what’s happening (delivery, opens, clicks, etc), which i didn’t have cleanly before.
I was using resend earlier but this felt simpler to work with overall.
still early days for them, but yeah… felt more aligned with how i actually build stuff.
This is something I’ve noticed too. Many email tools price based on stored contacts rather than actual usage, so even inactive subscribers can quickly increase the cost.
It makes sense for larger companies, but for indie hackers or early-stage projects it can feel inefficient, especially when you’re still experimenting with your audience.
I’m curious — do you think pricing based on emails sent (or active subscribers) would be a better model for indie projects? Or have you found tools that already handle this more fairly?
The contact-based pricing model has always felt backwards. Your bill goes up before you've sent a single thing. Ran into this exact thing building our company. Switched to outcome based pricing.
The overpaying-for-email problem is real, and it compounds fast — especially when most of those emails are going to customers who are about to churn anyway.
One related cost that's even more invisible: founders who send lots of "your payment failed" emails manually (or not at all) are leaving recovery revenue on the table. The average SaaS loses 9% of annual revenue to failed payments, and most of that is recoverable with a simple Day 1 / Day 3 / Day 7 sequence.
If you're already thinking about email infrastructure costs, it's worth calculating whether the emails you're not sending are costing more than the ones you are. A single recovered subscription at \0/mo pays for months of email overhead.
Try out keplars.com - plan starts with 5$ just and with 99% deliverability and 100% delivery insights
Hm. Since I'm just starting out, I don't have any email tools yet aside from my gmail account. I can imagine people overpaying because they think they need all the bells and whistles, especially those like me who are anxious about getting the best results possible. Do you have any recommendations on tools for this that don't cost an arm and a leg?
do checkout autosend - simple monthly sending volume based pricing
Many indie hackers overpay for email tools due to complex pricing, unnecessary features, and lack of awareness about simpler alternatives.