What is the differentiator here? Why would anyone choose this?
Fair question. Here are a few reasons: - Pricing wins against pretty much any provider (and is an order of magnitude lower than many incumbents). - Especially when compared to SES, we're a dev-friendly, fully modern sending platform and we don't require you to glue a bunch of services together. - We're self funded from previous acquisitions in the space. We're focused on good customer outcomes instead of investor out…
Show HN: Anypost – transactional and broadcast email API, 8¢ per 1k
11–20 of 22 posts
Re: Show HN: Anypost – transactional and broadcast email API, 8¢ per 1k
#12Re: Show HN: Anypost – transactional and broadcast email API, 8¢ per 1k
#13Good to know that the team has email industry expertise, but how does having this expertise differentiate you vs a competitor that, presumably, has team members with industry expertise as well?
Re: Show HN: Anypost – transactional and broadcast email API, 8¢ per 1k
#14Re: Show HN: Anypost – transactional and broadcast email API, 8¢ per 1k
#15Looks good. How’s your security? These days everything hinges on email for auth (particularly with email code sign in being so popular) so if there is a breach that’s a lot of exposure. Security is the one aspect that would make me hesitant to try a newcomer email API.
Great question and I'm happy to speak at least from the non-engineering perspective. The platform is designed such that we don't retain any customer data, we only process the email transactions, so that helps with the blast radius a bit.
We're also in the process of beginning our SOC2 audit to add some confidence through that lens.
Our team previously built a few products in email, including an end-to-end encrypted email service for regulated customers, so there's a lot we've learned and done in the past that informs how we build secure products today. I've also personally built compliance and security product strategy for large developer products which means security is a first-class discipline for us.
Dan, I'm sure, would be happy to go into more specific, technical detail but I hope this information is helpful still.
Re: Show HN: Anypost – transactional and broadcast email API, 8¢ per 1k
#16Re: Show HN: Anypost – transactional and broadcast email API, 8¢ per 1k
#17Looks great. Also great work on https://emailmd.dev
Re: Show HN: Anypost – transactional and broadcast email API, 8¢ per 1k
#18What is the differentiator here? Why would anyone choose this?
Fair question. Here are a few reasons: - Pricing wins against pretty much any provider (and is an order of magnitude lower than many incumbents). - Especially when compared to SES, we're a dev-friendly, fully modern sending platform and we don't require you to glue a bunch of services together. - We're self funded from previous acquisitions in the space. We're focused on good customer outcomes instead of investor out…
Re: Show HN: Anypost – transactional and broadcast email API, 8¢ per 1k
#19Earlier quoted context omitted.
Fair question. Here are a few reasons: - Pricing wins against pretty much any provider (and is an order of magnitude lower than many incumbents). - Especially when compared to SES, we're a dev-friendly, fully modern sending platform and we don't require you to glue a bunch of services together. - We're self funded from previous acquisitions in the space. We're focused on good customer outcomes instead of investor out…
A race to the bottom on pricing is just going to get you very low quality customers which in turn will tank your sending reputation. I think you're approaching this backwards.
If you allow spammers on your network things get a lot more expensive. So you can't offer low prices and allow low-quality senders. That's why we have a strict AUP and aggressive measures to detect spammers, phishers, and non-permission (aka cold-outreach) messages.
Re: Show HN: Anypost – transactional and broadcast email API, 8¢ per 1k
#20In addition, it's not immediately clear if SMTP is supported, but you might want to add that if not since it's the standard. Your api might be cool but avoiding vendor lockin is cooler.