How Building Our Own Campaign Mailer For Rails Set Us Free

This week Ben, Starr, and Josh break down Heya, their freshly shipped open source email campaign mailer for Rails developers. Learn how Heya works, how it can help with GDPR and Soc 2 compliance, and how it saves Honeybadger $$$ in Intercom and Segment costs. Plus, don't miss the hot thermometer takes!

Show Notes:
Links:
HeyaRuby WeeklyAction MailerIntercomCustomer.ioSegmentGDPRMixpanelSoc 2Prosperity Public LicenseMailCatcherGinsu Flex Tape
Honeybadger

Full Transcript:
Starr:
I saw some article about how some grocery stores like taking people's temperatures before they let them in.

Ben:
Yeah?

Starr:
And the one they showed actually projected, using a laser, the temperature reading on the person's forehead.

Ben:
Nice.

Starr:
And I thought that was so cool. And I was like, "I want one of those." And so I actually started searching for it. And I was like, "What if you want to take your own temperature?" Then you have to go to a mirror and-

Ben:
Shoot yourself in the head.

Starr:
Shoot yourself in the head. Yeah. Oh, yeah. I didn't even think about that imagery. That's kind of gross. Oh, Lord. There are all sorts of problems with that, now that I think about it. So, yeah. We just got an old fashioned digital thermometer.

Josh:
Every other morning. You just wake up and go into the mirror and you're just like.

Starr:
I don't know if you guys have this, but I realized that I have this thing sort of hung over from childhood, which was back when I was a kid, it was pretty common still for people to have mercury thermometers.

Ben:
I still have it.

Starr:
You still have one? Yeah.

Ben:
Yeah.

Starr:
Mercury thermometers are a... I mean, it might break. But-

Ben:
It's the gold standard, man.

Josh:
Yeah.

Starr:
It's the gold standard, yeah. That's what they use in chemistry labs, still use a mercury thermometer. But the one thing that I was always scared to do. They tell you when you're a kid, "Well if you bite down on it, and it breaks, then you're going to have mercury in your mouth." And that basically just means you're going to die immediately. I mean, not really. But that's the impression I got. And so even though our thermometer now is digital, I still have this anxiety. It's like, don't bite down on it. You know?

Ben:
Yeah. Honestly, I'd be more concerned about the broken glass in my mouth than I would about the mercury.

Josh:
The glass could be a problem. Yeah. Yeah.

Starr:
Yeah, I guess so.

Josh:
Yeah we have one of the forehead contact ones, and it works pretty good. Yeah.

Ben:
Yeah, the reason why we have four thermometers is we had the original, the glass one. That was our first one. And then we upgraded and got the digital one when the first kid was born. And then at some point later, we got one of those forehead ones. And that was great. And then when the older one went off to college, one of the recommendations from... They had the orientation for parents as well as orientation for the kids.

Ben:
And the orientation for parents, they said, the medical person got up and said, "If you don't send anything else with your student, send a thermometer." Because they get so many reports of kids not feeling well. They could have called the clinic and say, "Hey, I'm not feeling well." And I'm like, "Well do you have a fever?" And the kid's like, "I don't know." And they're like, "Well do you have a thermometer?" And the answer's always, "No." So they said, "So please send them with a thermometer." And so we got one. We got a thermometer and set him up. Now he's back at home, so now we have four. So that's how we have four thermometers in our household.

Josh:
Smart. Yeah, I can imagine not many college kids have a thermometer.

Starr:
All right. So today I think we're going to take a mild break from simply talking about the fact that everything outside of our little bubbles is on fire, and we're going to talk about some cool news that Josh actually shipped something, and we're going to talk about it. And that thing-

Josh:
Josh and Ben.

Starr:
Josh and Ben. I'm sorry. I'm sorry, Ben.

Ben:
But mostly Josh.

Josh:
Ben did all the cool stuff.

Starr:
Yeah, I'm just saying I didn't do anything. That's all. That's why I'm announcing it. Yeah. So this week we released Heya, which is Josh's sort of email marketing gem Rails engine thing. So what does it mean to say that we released it? What's the state of it?

Josh:
Well it's been on our GitHub, if you went and looked for it, for a few months at least now. It's open source. It's just a GitHub repo. But this week we announced it and started talking a little bit about it. I posted on Reddit. And then it got picked up by Ruby Weekly this week too. So that kind of got it some attention, and more people know what it is now. Which is, it's basically a campaign mailer, like a sequenced mailer, for Rails. So it works kind of like, I don't know if you're familiar with Action Mailer? Sending you just vanilla emails in Rails. This basically feels just like Action Mailer, but it lets you send sequences of emails. And the emails within sequences can be segmented. So you can send different emails to different people who enter a campaign. So it's very similar to Intercom or Customer.io. But it's a direct plugin self-hosted in your Rails app with direct access to your user database, which is my favorite part.

Starr:
Yeah. And it's a little bit timely, just sort of accidentally, because the main reason that Josh sort of really wanted to do this, let me just talk for you, Josh. Let me speak for you.

Josh:
Yeah, please do.

Starr:
Or that we wanted to do this is because we were paying a really large amount of money to Intercom for essentially this one feature. Are we allowed to say how much money we spent? Does anybody remember?

Josh:
Yeah. Well we were paying... It was around a thousand a month, I think, at one point. And then that's also not including Segment, for instance. We were using Segment to send our data to Intercom and a few other places, and that was another $400 a month. So we were probably all in for $1500, $1400/1500 a month I would guess.

Starr:
Okay. So it's a pretty big chunk of change.

Josh:
Yeah.

Ben:
That was even with trimming the user database from time to time, to keep the cost down.

Josh:
Yeah we were doing all the stuff. We were doing all the things that people do with Intercom.

Starr:
Because they go by the user, right?

Josh:
Yeah.

Starr:
So you can't actually store all your users in there. You've got to-

Josh:
Yeah.

Ben:
Yeah.

Josh:
And when we say user, we mean user in your database, not users that can use Intercom. It's how many users of your app you are wanting to message. So we were storing just our active users, and still it was astronomical.

Ben:
Yeah. Which in fact kind of makes the product worse, because you end up... Like the users that aren't active might have sent you a request a few months ago, and if you decide to be aggressive at purging, then now you don't have that context for that user. So it's frustrating as well as expensive.

Josh:
Yeah.

Starr:
Yeah. And maybe you want to send some reactivation campaigns to old users, or something like that.

Ben:
Right.

Josh:
Yeah.

Starr:
Or maybe you want to get in touch with people. Having the old users in there isn't as valuable obviously as having your current users, but it's still useful, and it's kind of crappy that having all your users in there is prohibitively expensive.

Ben:
Yeah.

Josh:
I hadn't thought about that part. If you can't send re-engage, reactivation campaigns to old users, maybe Intercom is even more expensive than we thought.

Ben:
Yeah. And also speaking for Josh, another problem that we had was just syncing the data over, because you want to define segments for people, to send them different kinds of emails depending on what they've done in the app. And always keeping that data in sync is problematic, and thus Segment.

Josh:
Yeah.

Starr:
Yeah. If you haven't ever set up Intercom before, basically you have to send all your sort of user data that you want to be able to use inside of Intercom, you have to send it to Intercom. So anytime it changes in your app, you've got to update it in Intercom. It's one of those things that's just a real pain in the neck to consistently do right, or just to maintain.

Josh:
Typically it's your user data, which consists of a collection of properties per user, so attributes. And then events. So what they're doing. The activity that is happening in your application and elsewhere in your system. And the use case for Segment is that there's all these kinds of different marketing platforms like Intercom, or for instance Mixpanel or something, that do different things with the same data, basically. And so you have to send it everywhere. So you might be sending it to six different sources, or destinations I mean. And Segment comes in and basically you can send it to them, and then they act as the central repository that sends it out to everything else. And that solves a problem, I guess, if you're using six different things, and constantly changing things, but we weren't. And I came to the conclusion that that's just crazy overkill for us. We didn't need that. And we struggled with that whole setup for years before we finally got around to replacing it. So what we have is just a little gem for Rails now, and I like it a lot.

Ben:
I had some of my own frustrations with the setup. One was if you want to create a segment, a new segment, in Intercom for a new attribute. Let's say a person has this feature. You wouldn't have that data in Intercom, because you didn't put it in there before. Maybe it's a new thing. And you have to go back and do a backfill for users that had that thing happen at some point in the past, but you weren't tracking it. You weren't sending it to Intercom yet. So that got us. It's just annoying how you have to go, "Oh, okay. I want to email these people. Oh, but the data's not up there. I have to go send it over there."

Ben:
And then from a privacy standpoint too, me being the compliance person, I get kind of twitchy when we have to send data out to third parties. And of course being GDPR compliant, we have to tell our customers where we're sending the data that we process. And giving this to Segment, giving this to Intercom, and whoever else that we're sending data to. And it's just more kind of a hassle.

Josh:
The GDPR made that a lot more... because the user case... When we signed up for Segment, it was because we didn't really know what we needed, I think. Like what tools were going to stick. We were trying a bunch of things, as I recall. And I think we were trying Mixpanel, we were trying Intercom, we were trying different things. We hooked it up to our Google Analytics. And the real nice thing back then was that you could basically just turn it on with the click of a button in Segment, and your data starts showing up. So you can try any service basically without any integration, once you do the first integration to Segment.

Josh:
But after GDPR, it's like sure, you can click all those buttons, but then you got to add like six different new things to your DPA, and go through and notify all of your customers that you did that. And that alone, it kind of like talks us out of trying new things, to be honest.

Ben:
That's true.

Starr:
Yeah. I feel like I should mention that GDPR is a privacy sort of regime that was instituted by the European Union a while back, I think. So basically if you send data to third parties, you've got to notify your users if you send that user's data to a third party. Basically you have to get consent for everything. 

Ben:
If they are just doing your stuff, then it's fine. But then even that though is for GDPR, it's protective. But there's SOC 2. There's the other kind of compliance that they've been working on. And that is different, because that, every vendor that you use that you send any kind of data to, you do have to keep track of. You do have to make sure that they are also doing the same kind of principles that you are committing to doing with SOC 2.

Starr:
It's a lot more strict.

Ben:
Yeah, it is. So you have to keep track of all that, and that's a hassle too. So any third party that you can remove from receiving your data is a good thing.

Josh:
Yeah, and this is making it, especially for small businesses that don't have people to sit around and just deal with this stuff all day, as Ben has found out. Yeah.

Starr:
So how far in the SOC 2 process are we, Ben? If you're comfortable sharing that.

Ben:
Yeah. We are getting close. And by close, we're probably within months.

Starr:
Oh, really?

Josh:
I was going to be like, is that a few years out?

Starr:
Because you've been working on this for a year already, right?

Ben:
I don't know if it's been a year. But it has definitely been at least six months. But, yeah. We did this past week sign an agreement with an auditing firm. So we are on track to actually get that done. The one thing that's really cool that I didn't know about, until I talked to this auditing firm, is we've had customers asking us for our SOC 2 report, which we don't have, because we haven't gone through an audit. And so what I've been telling customers is, "Sorry. We don't have that. Here are the things that we're doing. But we're working towards that."

Ben:
But the thing I learned this week from that auditing firm was, they're actually happy to give you basically an engagement letter saying that, "Honeybadger has engaged with such and such firm to do this compliance audit." And that's a way for you to actually somewhat prove to people who are asking for this report that it's not here yet, but it's on the way.

Josh:
That's cool.

Starr:
Oh, nice. That's great. That's great.

Ben:
It's pretty cool.

Starr:
Yeah, and when that happens, we will be one of very few companies in the space that actually offer this, I think. Offer SOC 2 compliance. Which is going to be important, because if you want to offer SOC 2 compliance, then you got to have your error report handling service that's also SOC 2 compliant.

Ben:
Yeah.

Josh:
Another cool thing that I didn't really think about is this helps us with even future things that we might do, because I assume now that our company is SOC 2 compliant, as long as we follow these guidelines for anything new we build, that is also compliant, right? So this kind of goes a long way it seems into the future for helping us out.

Ben:
Yes. Yeah. That's true. It definitely gives a good selling point. Part of the compliance audit is you do give them a system description.

Josh:
Okay.

Ben:
Basically you describe what you do, how you do it, where does data go, so that they can get an idea of kind of what the risks might be. So if we create a new line of business, let's say. We would have to amend that description and say, "Okay, now we're also doing this." And then have the next audit include that. But, yeah. You would be definitely starting from a much more advanced point than starting from scratch. Yeah.

Josh:
Yeah. That's pretty cool.

Starr:
But you know what? It doesn't even matter for Heya, because it's self hosted.

Ben:
True that.

Josh:
Exactly.

Starr:
Anything that a business self hosts, you don't have to get a third party compliance report from them, or anything like that, because it's on your own hardware.

Josh:
Mm-hmm (affirmative).

Ben:
Indeed.

Josh:
Yeah, that's one of the big selling points, I think. Yeah.

Ben:
Speaking of selling, it's not just an open source gem. Right, Josh?

Starr:
Oh, yeah.

Josh:
Yes. It does have a price attached to it. So we're using this new... It's a new open source license called the Prosperity Public License. And what this is, is it's kind of like a hybrid. So it's free for nonprofit or noncommercial companies. It has a 30 day trial for anyone else. And then after that, if you're a commercial business, then you're required to pay. We actually are also extending that, the free version, to any small businesses, like bootstrappers and stuff. So if you have less than 1000 users in your application, then you can use it for free, just like as if you were a nonprofit, basically.

Starr:
Because let's be honest, you probably are nonprofit.

Josh:
Pre-profit, Starr.

Starr:
Pre-profit. Oh, sorry. Sorry. I didn't mean to be too negative there.

Josh:
Yeah. So, yeah. The price tag right now is $99 per year, which is pretty low. We weren't really sure what to charge for it, and it's a new gem, so that is likely to change in the future as more people use it, and I have a lot of ideas to add to it. So if we actually get there, I think it'll be going up a little bit. But, yeah. That's kind of the introductory price.

Starr:
Yeah. We discussed this I think in the last conclave, which was that yeah, we're going to price it, give it sort of introductory pricing just to test the waters and see how people respond, see how people use it in the real world and everything.

Josh:
Yeah. This whole model, we've explored the open core model a little bit. That's kind of what Sidkiq, for instance, the Ruby background processing gem. It has a free, completely open source, true open source version. And then it has a pro that's closed source. A pro version. And you can buy that and it comes attached with a separate license, I think. But this is different from that in that everything actually is open source. You can go read all of the code on GitHub right now. So there's much more of an element of the honor system in this approach. It's kind of untested. Uncharted territory, at least for us, especially. So we're kind of going to see how it works. But, yeah.

Josh:
Actually we came up with some pretty cool licensing key scheme, which basically we can generate license keys for people when they purchase. Right now, the only thing it is does is it basically removes a warning that says, "This is the free version." I don't know if we we'd actually ever gate features or anything like that within the gem. But that would all totally be doable.

Starr:
So we mentioned earlier that it's kind of a replacement at least for our use case of Intercom where we were having these email campaigns that can be triggered by things, by users' actions within the application. They are sequences, meaning you get sort of emails dripped out across time. And in Intercom, I know how you do things like that, how you set this up, where you go into this user interface and you say, "Okay, I'm going to define this segment of my users, which is users meet criteria x, y, and z. And then for each of these users in this segment, do this series of emails." And Heya is a completely different approach. And I was just wondering if maybe we could talk a little bit about what setting up one of these campaigns actually involves. Maybe like an actual example of some way that we're using it in our app. Just to give people a little taste.

Josh:
So currently there is no UI, no graphical UI for Heya. It's all command line and Ruby files, which we like, because we're Ruby developers, and we're mostly just managing the content ourselves. So we don't mind digging into the Ruby to add new emails, or create new campaigns and stuff. So I really like that approach. I kind of look at this like... So basically with Heya, every campaign has its own file. It's one Ruby file where you would define the steps of the campaign. So each step has a name. And each step has basically an email that is sent. So you can have options for each step, like how long it should wait between them. You could segment who's the step actually going to send to. Or people that don't match, you're going to skip to the next one.

Josh:
Like I said, it's similar to Action Mailer. With Action Mailer in Rails, Rails stores those mailers in app/mailers, the directory. Campaigns with Heya are stored in app/campaigns. So it's very similar mapping there. So each campaign maps to a file. And then the templates and stuff are all basically just Action Mailer to the hood. So if you know how to build in Action Mailer a Rails email, you know how to build a Heya email, basically.

Starr:
Yeah, and there's a couple things that may not be completely obvious I just want to call out that are actually huge benefits of doing it this way. It's not just about we want to be programmers and do things in this programming way. So a couple things. First of all, when you define your email sequences in code, these get checked into your version control system, right?

Ben:
Mm-hmm (affirmative).

Starr:
So if you screw it up, you can go back and revert to a previous version. You can do all this stuff. Which if you've ever edited campaigns in a tool like Intercom, it's just this visual thing.

Josh:
Yeah. It's terrible.

Starr:
Yeah. Who knows. Who knows. You have no way of tracking anything about how that's changed over time, or who originally set it up, or anything like that. So that's one big benefit. And the other big benefit is that you can actually test these things. You can write unit tests to make sure that your email sequence is executing in the way that you expect it to, given certain conditions. Like users with certain attributes and stuff like that.

Josh:
There's also segmenting, which is tying into the testability benefit. To me it's huge, because most of the email automation tools are fine if you're just doing the bare minimum, like if you're just sending a drip email sequence, basically. But if you start to get into complicated workflows, or you have a lot of complicated segmenting logic, like different groups of users who are getting different emails at different times, and all that sort of stuff. You're basically programming within those interfaces, because you're creating all this logic that is going to dictate what the system does. However, testing does not exist in that universe. So aside from just your standard QA. Using it, trying to make sure it works.

Starr:
Is this why every month I get some apology email from some random companies?

Josh:
Yeah. "Oh, we didn't mean to send that."

Starr:
"Oh, sorry. We didn't mean to tell you that your account was expiring," or "you needed to change your password," or whatever.

Josh:
Yeah. Yeah. Exactly. And to be honest, it's surprising to me that that doesn't happen more often. I suspect it actually probably does, but it's email, so you can't necessarily always see what's happening either, or notice it. But, yeah. It's very easy for your workflow logic to misfire or not work like you thought you set it up to work. With Heya, the segments are basically, well not basically, they are just Ruby code that's basically on your user model. So a segment is literally just a proc that a user has passed into, and then you can return true or false, and that user is in that segment. So you can test that.

Josh:
You probably already have most of your segmenting logic built into your user model already. At least we did. And that's another problem we had with using the third party, using a bunch of services. They all have their own versions of segmenting. And if you're doing it at the edge, if you're building your segments into Intercom, then basically if you want to use those segments anywhere else, you also have to build them into those other tools. So then you're managing custom logic in a bunch of different places with duplication, which is just, yeah. It's terrible.

Ben:
Yeah, I think it's so cool that you can have your logic right there in the app for which emails get sent when. You can check and is this user paying? Or does this user have this feature? Or when was the last time this user logged in? All that kind of stuff is right there, because you are dealing with the user model that's in your app.

Josh:
I've learned over time that's a best practice in general. I like to keep my segmenting logic as close to my application and my single copy of user data as possible. And that's one reason you probably don't want to just send all of your properties to services like Intercom, because then you end up basically... If all you have are your properties, you're having to recreate those segments based on the property values on changes and stuff. Whereas if you actually computed your segments in your application and then sent them out, you have that, the result of that to Intercom. Or all of your other tools. Then they're all getting the same thing and you're not duplicating the logic, basically.

Starr:
So let me throw out an example and see if this is what you're actually talking about. So you're talking about instead of just saying... Imagine your user table in your database has a field that's like projects count that has the number of projects this user has created. Instead of sending that directly to Intercom, and then Intercom being like, "Well we want to have low usage people." So we're going to create a new segment in Intercom that says if projects count is less than five, or whatever, do this thing. So you're suggesting the way you would prefer to do that is to do that in the code itself and send maybe an attribute for that user that says low usage user directly to Intercom.

Josh:
Yeah.

Starr:
And then just check that sort of Boolean inside of Intercom?

Josh:
Exactly. Yeah, because you're adding a conditional, so that's logic. Basically you have the if statement in Intercom if you're saying project count is less, or whatever, than five.

Starr:
You know what? That just sounds like a whole lot of work anyway. It would be so much easier if you just did this all in your code and yeah, that way you could just have a single copy of your data. You could have a single copy of your logic. You wouldn't have to be sending stuff all over the place.

Josh:
Exactly. With Heya you don't have to worry about-

Starr:
I mean, who are we? FedEx?

Josh:
Yeah. Yeah. Well I think Segment is, or something. I don't know. It's interesting though. The martec industry, which is marketing technology, that's the cool word for all of this stuff.

Starr:
It sounds really cool.

Josh:
Companies that are dealing with this problem on a mass scale are the reason for Segment's existence. Segment is solving that problem for companies that can't just build everything into their app, for whatever reason. So it's interesting. One of the features that Segment came out with, within the last couple years anyway, I feel like it was within the last year, is the ability to basically you can do that. They now have segments where you can define your segmenting logic in Segment. And it basically stores it in your data warehouse. And then they forward those values on. So basically they're computing your segments in one location. They're kind of acting as that intermediary. And then they send the values out. So it's the same thing.

Josh:
But that led me to think, why do we need Segment in there if at this point we're only using a couple things in the first place? So I kept just walking it back and realized we really just need to send some emails with some logic, and Ruby's great for that. We love Ruby. So let us use Ruby.

Starr:
Yeah. The only downside really here is that a person who's not a developer realistically can't add a new email, can't do any of that. But honestly, with all the stuff we've been talking about, about all the work it takes to send this data to Intercom and stuff, it seems like half the time a pure marketing person wouldn't be able to do that anyway, because they'd be relying on some data that wasn't present, or something like that.

Josh:
It's a lot to manage. I think, again, companies that have big marketing departments with a bunch of people that can dedicate their entire workdays to managing that stuff, sure. But it's been a lot for me to manage as a developer doing marketing. So it's got to be a lot for a non-developer doing marketing to do the same thing, or more.

Starr:
Definitely.

Josh:
Heya also supports Markdown, actually via a different gem which is really cool called Maildown. So it's very easy. You could have your marketing people, non-technical people, most people are learning to write Markdown these days. So you can still have non-technical people actually producing content, for instance, write in Markdown. Basically, you just copy it in, and that's it.

Starr:
Oh, that's awesome.

Josh:
So it's really not that hard to set these things up.

Starr:
Can I just also mention one other cool thing about the testing? It may not actually have much to do with Heya, but the fact that Heya is built into Rails and it uses... Does it use Rails Action Mailer stuff under the hood?

Josh:
Yeah.

Starr:
Okay.

Josh:
Yeah, you can use basically all of that stuff to your benefit.

Starr:
Yeah. So what that means is that you can actually test the content of your emails.

Josh:
Yeah.

Starr:
I don't know if our beautiful listeners have ever been setting up a campaign in a tool like Mailchimp, or whatever, and you find that when you send it, the mail merge tags didn't work right, or whatever. And yeah, you can send test emails, and you can do all this stuff. But it's so awkward, and it's so easy to miss things. So just making sure that the email is rendered correctly with all the mail merge tags in there. With maybe different types of data, different links of strings and stuff, and being able to sort of look at that. And in addition to the unit test, Rails also has a... I forget if they built this in is at this point. Do they have the... Is it built in where?

Josh:
The previews?

Starr:
What?

Josh:
The previews.

Starr:
The previews. Yeah.

Josh:
Yeah. It is.

Starr:
It's got a built in preview thing now where you can, by now I mean like within the past decade, where it runs a little server and you can basically see any emails that it sends out, like the actual HTML of it in a browser, like a mail client. And it's so cool. All that infrastructure is amazingly useful.

Josh:
Yeah. Yeah. So you really don't have to send test emails at all when you're building a campaign with this approach, because you're doing a test driven approach, so you're doing the testing with whatever, RSpec MiniTest, or whatever. And then if you do, of course you probably do want to see what the emails look like. There's a lot of different tools in Rails that basically can act as a... There's MailCatcher, for instance, that will act like an email server and let you see what it's sending out. So it's a very nice integrated environment to build out your marketing campaigns, basically.

Ben:
And then there's also localization, right?

Josh:
Yes.

Ben:
You can use those localization strings.

Starr:
Oh, shut up, Ben. We're including localization too?

Ben:
Yeah.

Josh:
Yeah.

Starr:
We can't afford this. We can't afford to do it. Stop the recording. We can't afford this.

Ben:
We're giving the whole store away.

Starr:
Yeah. You're giving away too much, Ben.

Josh:
You know what the best part of all of this is, is basically we're just selling you Rails. Pretty much what Heya does is it's the scheduling which is the magic, the scheduling and the segmenting. But even that, all of that stuff under the hood is taking advantage of all the awesome stuff that you get in Rails for free as well. So it's an extremely good deal.

Starr:
I feel like if this Honeybadger thing doesn't work out, we can always just sort of go on the roadshow and do some sort of super shammy roadshow at fairs and carnivals and stuff.

Josh:
Just be like Rails advocates, or something.

Starr:
Yes.

Josh:
Or is this non-tech? Like we're going to go just to the roadshows?

Starr:
No. Like super shammies.

Josh:
Okay. Yeah. That's nice.

Starr:
Yeah. Or whatever. Like Ginsu knives or-

Ben:
For a limited time, every purchase of Heya comes with a free roll of Flex Tape.

Starr:
Oh, there you go. Flex Tape. Yeah.

Josh:
Flex Tape. Yeah.

Starr:
Yeah. We talked about how much you love that stuff.

Josh:
Yeah.

Ben:
Yes.

Starr:
I feel like we need the technical version of Flex Tape. You could make a lot of money if you have the technical version of Flex Tape.

Ben:
It's called Perl.

Starr:
Yeah. It's called Perl? Oh. It's like your queue's dropping jobs. Your web servers are falling down. Just put some Flex Tape on it.

Josh:
Slap some Perl on it.

Ben:
Totally.

Josh:
So in the future, right now Heya is basically what we just described. It's a campaign mailer. It's all in. It's a developer tool in Ruby. There's a lot of interesting things that we can do with it in the future though that I think could be interesting. So for instance, I think I just said interesting like five times. So for instance, the way I designed the campaign scheduler and basically the DSL that you use to build these campaigns in Ruby, it's designed so that it could potentially also work with a UI. So we could actually build a graphical user interface for this that would mount it to your Rails app, and then you could have your marketing people add campaigns and manage the content in them, and all that normal stuff. So I haven't decided if that's actually something that I would want to add, because personally, I prefer the way we just described, for all the reasons we just said. But it's got some interesting technical possibilities.

Ben:
That'll be the Heya platinum edition.

Starr:
Oh, there you go.

Josh:
Could be. Yeah.

Starr:
I've been feeling-

Josh:
I guess we'll see if enough people use it. Hopefully I'll get some feedback and see what they want, and then I'll probably just build that.

Starr:
Yeah, I have a feeling a lot of this is just going to depend on the feedback we get from people who use it.

Josh:
Yeah.

Ben:
So if you're a Rails developer, you should go and check it out and use it, and ask us to do some stuff with it. And we will.

Josh:
Yeah. And you can find it at Heya.email. That's the domain name. Heya.email.

Starr:
Heya.email?

Josh:
H-E-Y-A.

Starr:
And can I just make a suggestion? So in these uncertain times, we're all going to be tasked with cutting expenses and doing all this stuff. And some of us may face a choice of okay, do we need to cut out the expense of our error monitoring system? Which is a hard choice. But I'm just saying, Intercom is in general much more expensive to use than Honeybadger is. And so we are graciously offering you this chance to cut Intercom instead of Honeybadger.

Josh:
We're offering them in our place?

Starr:
Yeah. We're offering them in our place, because that's just how we like to do business.

Ben:
A+, would offer again.

Starr:
Would offer again.

Josh:
Got it.

Starr:
And honestly, we got to claw back some of that money that we gave them.

Josh:
We gave them a lot of money.

Starr:
Yeah. We can get some of that back now.

Ben:
Yeah, that makes me think, we did have a process for migrating off of Intercom and onto Heya, right?

Josh:
Yeah.

Ben:
So we probably document that for people who are also interested in moving off of Intercom.

Josh:
I've got a bunch of things I should write. I've got a list of documentation stuff. But yeah, I think it would be cool to kind of go through the process that we came up with for migrating, because there's a number of different steps, different points. We haven't even talked... I think we talked about maybe in a previous episode, but our move to HelpScout from Intercom was the first step in all of this too, because initially we used more of Intercom. So we were using it for support as well as for onboarding emails. So the first step was to get our support out of there. Which we're much happier with, I think, in general as well. And then yeah, basically for us, it just left the emails we were sending. So that's where Heya came in. And once we moved to that, we were able to ditch Intercom entirely.

Starr:
So you're saying the next step for Heya is to build a support system tool called HeYelp?

Josh:
If I do, that will be the name, for sure.

Starr:
Okay. Thank you.

Ben:
I love that. I love that name.

Josh:
Yeah. I got to go. I should go snag that gem name, just in case.

Starr:
Yeah. Yeah. All right. So it sounds like we're wrapping up. Anybody have anything else they'd like to add?

Ben:
Nope.

Starr:
This has been FounderQuest. If you enjoyed listening to us, go give us a review on Apple Podcasts, whatever it's called. And if you want to write for us, we are hiring people to write in the vein of Ruby tutorials, Elixir tutorials. We talked about maybe getting Node. Maybe trying something in Node. I don't know. But, yeah. It would have to be good one. So go to our blog. Look at the top navigation bar area. There's a "write for us" link. And read that page and contact me in the manner specified. I do accept bribes. Just FYI. So this has been FounderQuest. And we'll see you guys later.

Episode source