I understand that it may improve "engagement" and reduce churn, but gosh I hate those "follow-up" emails.
For example, I'm currently trying out PagerDuty, and those pesky emails about "how to configure whatever you've already configured" are really annoying. At least, please take a few minutes to code something to check if your "beloved new customer" already have done what you are suggesting them to do.
My time is quite precious. Please don't waste it by suggesting things you can figure out I already know.
100% agree on the companies overdoing email automation. Just look at my "Promotions" tab in gmail. 1000 unread.
I believe one of the reasons this happens is limited trigger types for email sequences and even more limited support for customizable content in the email (I know Mailchimp does this). Because of that you are left with primitive trigger types like time than something more granular like trigger based on user app activity.
By bringing the automations closer to the application source code, I believe you can build in "engagement" and "rentention" mechanisms that don't suck.
Eventually, once SaaS subscriptions become more commonplace among the rest of the population, a significant number of people are going to be annoyed by the disconnect between the automated emails they receive and the features they’ve already tried out as a new user.
One or two people will see an opportunity and take VC money to fix the disconnect: a way to make email automations smarter by deepening the integration between ESPs and SaaS code bases, as you have done with this oss project.
We use Intercom and Mixpanel for VisualSitemaps.com.
Sadly their Mixpanel "integration" is very basic and does not sync up the most important engagement data which Mixpanel tracks for discreet features. So the only way to set that up is with by writing your own custom api syncing().
Website nit: the "npm install --save-dev candymail" installs this as a devDependency which is normally reserved for development tools like TypeScript, linters, etc. Things which are not needed at runtime. Your library is definitely needed at runtime so "--save" is the appropriate flag.
You should not ask for a users gmail username and password; there is a way to generate an authentication key for your app that allows the user to revoke the access later as well. I do the same for my mail delivery system.
It's quite easy; here is my C# console app that generates the creds and uses it to send an e-mail. https://imgur.com/a/ZjZUFqS
I was worried about the username/password too. Interesting, so you're generating a Client secret and using the Google package to send emails. That snippet helps a lot! Also found the relevant guide for Node.js - https://www.google.com/amp/s/blog.mailtrap.io/send-emails-wi...
I build indie side projects all the time and having an email automation is always an afterthought. Plus MailChimp automation is too expensive and to clunky.
So I decided to spend my Christmas holidays building an open source package called Candymail.
Candymail makes it easy to trigger and send multi-step email sequences in Node.js using a single JSON file.
Looking for some feedback, does it sound useful? Thank you And happy holidays :)
I'm in the US, so it would be illegal for me to deploy this without unsubscribe functionality.
I can't think of a quick and easy way to do it in your lib right now, but this kind of thing is pretty much why I use MailChimp/Sendgrid/etc. for even tiny projects.
There's no reason your app has to manage unsubscribes internally, this can be left up to the developer using your package to implement themselves. But it would be good to call it out in your docs that it's something they need to do.
If you have to manage unsubscribes yourself, you might as well use MailChimp or something similar. You'd probably lose a lot of dev time if you use this lib and then add onto it vs. something that works out of the box.
Unsubscribe should definitely be part of this. Or at least a way to stop the emails from sending after a user has unsubbed, otherwise we enter dodgy GDPR complaint territory. Maybe a dealbreaker even. Cool product otherwise! Will keep an eye out for a chance to try it.
Currently only gmail since it was the easiest to implement. I would love to add more providers for better deliverability and overall not-going-to spaminess (not ideal to send bulk emails from personal gmails). What providers would you like to see?
I'm probably in the minority here because I actually appreciate follow-up emails. Sometimes I get a message and feel lukewarm about it, ignoring it entirely, but by the follow-up have definitely made up my mind. Other times, I intend to get to a message but just fail to because of ADHD or life events and a follow-up is a convenient reminder.
If I dont like the message, the delete button takes a fraction of a second (my mail client [spark] makes it easy to actually just select a ton of emails at once and mass-delete) so it's really not an inconvenience to me at all. If I despise the message, the spam button also exists.
I'm not sure what the big fuss is people make about email all the time, but I'm thinking it might be time to just reassess how you manage your emails rather than blaming the people sending the messages.
You’re not in the minority, and even if you were, you’d be in the majority of people that actually pay for the product. Marketers send these emails because they work.
Marketers send these emails because they are free and they see some engagement. There is no metric to calculate whether their customers are upset receiving these mails. Whether it‘s an effective method is not clear.
But it is not intelligently used (only send follow ups if e.g. not created task in a todo app) by almost anyone.
I would definitely like to add some persistence in case the app crashes. What's better in this case - To use localStorage or save in a file? Any other ideas?
I appreciate the motivation behind this and the effort involved, but this is exactly what causes the stigma for the JS ecosystem.
“Fire off emails!”
It only works with Gmail, which will limit you. And only with user and pass, which is insecure.
No unsubscribe.
No persistence.
No SPF or DKIM, etc.
This is someone trying to solve a problem that has no real grasp of how big the scale of the problem is. There is a reason companies like Sendgrid exist, but we’re trying to recreate them for “hackers” and startups now. Great...
I share your concern completely. This is just something hacked together over a christmas weekend. The points you mentioned definitely need to be addressed before this library can even be called production-ready.
Though I would push back on the notion that because the problem is big and big players already do the job, why even try. There's a huge number of indie hackers, bootstrappers with small projects that can definitely benefit from an open source solution like this than have to pay $30/month.
I have already tabulated the items needed to make this a quality package and not just another hacky js library. I would invite you to keep track of the project and keep us honest :)
I disagree that anyone needs to spend $30/m on it. Sendgrid offers 100/day for free. I think all of the groups you just mentioned would fit well into that category.
Hey keyle, your points are right on the money.
1. sqlite is a great idea for persistence. It would be an in-memory db right?
2. There is a stop method already. I should do a better job of highlighting that in the README. But you can stop all messages from being sent out by: mailcandy.stop() or you can clear all the upcoming messages while keeping the timer going by: mailcandy.clearAllScheduledMessages()
3. Added to backlog. Are there any mail servers you would like to see?
SQLite does have an in-memory option but you don’t want to use that here, otherwise it won’t actually be persistent. It’d get destroyed when the app restarts. You want SQLite to persist to a file.
I think OP meant stop as in “unsubscribe”. Ability to unsubscribe is required by law in a lot of places, I’d definitely want to have that in place.
This kind of use case falls under “transactional email” and there are lots of providers you can use for that. Mailgun, AWS SES, Postmark, Sendgrid, and a ton of others. They’re purpose-built for sending one-off emails like this.
1. Yep that makes perfect sense. A persisted file keeps the data and the SqLite provides an easy interface to work with.
2. I mistakenly thought it wasn't important. But I've moved it to the top of the backlog, should be available soon.
3. This is gold. Looked into transactional emails and that's exactly what's needed. Moreover, there's projects like nodemailer-mailgun-transport that will make this easier.
Yep it's definitely dangerous. By design, you cannot turn on 2FA when using this setting. @NKCSS mentioned that you can send emails without touching this setting. That might be a more secure alternative.
Yep super.so as well. We got early bird pricing as well so super happy. Notion + Super makes it really easy to iterate on landing page copy without the hassle of deployments, styling etc. God Bless them!
For example, I'm currently trying out PagerDuty, and those pesky emails about "how to configure whatever you've already configured" are really annoying. At least, please take a few minutes to code something to check if your "beloved new customer" already have done what you are suggesting them to do.
My time is quite precious. Please don't waste it by suggesting things you can figure out I already know.