-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move email list to database #694
Comments
Why are we storing the template in mongoDB, and not an S3 bucket? |
This issue is actually for storing the mailing lists inside the database. Are you talking about #695 |
I think this is a lot more involved then it might seem on the surface. Emails that aren't transactional in nature (i.e. not emails regarding application status, account detail, etc...) are subject to anti-spam and unsubscribe laws and regulations. When you use something like Sendgrid Marketing, Mailchimp, etc... they handle all of that unsubscription logic. I have a hard time believing that the additional cost of the marketing emailing services is worth this headache and the dev time. |
@logan-r suggested that we do this to save on some money each year. Regarding unsubscribes, I think SendGrid can have that enabled even for transactional API emails (https://sendgrid.com/docs/ui/sending-email/subscription-tracking/) |
I still don't see this as being a good fit for what the HackerAPI does. Marketing emails for non-registered people is a pretty different use case. If you really want to save money might as well just write a bash script against sendgrid's APIs. What's the benefit of this being in the same codebase and database as everything else? Sendgrid's marketing plans start at 15$ a month. I find it hard to believe that the math makes sense on investing notable dev time into this for the 4-5 months a year it'd be used... |
I agree on the fact that this isn't too good of a fit with hackerAPI and could be developed faster + easier as an internal tool of some kind, but @logan-r and @loreina felt that this meshes in well with the staff dashboard. Some potential advantages with this approach could be that API auth code would not have to be duplicated. Regarding a bash script, the consideration here is that a web UI would be easier to use for the coms team. I am not sure how much money we spend on SendGrid Marketing or the overall event budget but I was informed that it was a notable chunk of money that could potentially be put to better use. Maybe we send a lot of emails in certain months so that we're actually spending several tiers beyond the basic one? Definitely agree that further consideration should be had on the matter before further dev time is invested in this project. |
What user stories are we trying to implement? Is the idea that marketing folks can send out email blasts from the website itself? |
The text was updated successfully, but these errors were encountered: