FounderQuest
FounderQuest
We Pull Back The Curtain On A Secret Project
Show Notes
Links:
IntercomHelp ScoutZohoUnixSegmentJosh Pigford
BaremetricsHaskellKramer SoundsSQLPostgresSQLHey Ya (song)Write For Us
Full Transcription:
Josh: Should we have to all say 'Badgers when we clap instead of just you, like we all say it?
Ben: Yes, but in different languages.
Starr: Yeah, and it's all going to come back in slightly different line times. So it's just going to be like 'Badgers, 'Badgers, 'Badgers.
Ben: Mushroom, mushroom, mushroom.
Josh: Mushroom, mushroom. Nice.
Starr: That was... What was that from? That was from an ancient meme, wasn't it?
Ben: Yeah, it was a video.
Josh: Badger, badger, badger-
Ben: Badger, badger, badger, mushroom, mushroom.
Starr: Oh! Yeah, yeah, yeah, yeah. I got it. I was totally referencing that. I was totally referencing that, guys. So have you guys heard the song Raining Tacos?
Ben: Nope.
Josh: Mm-mm (negative).
Starr: Because my little girl is super into it, and it's a song about it raining tacos. I think it's new, but it's a very old school internet type song.
Josh: I haven't heard that one.
Ben: Have you shown Ida hamster dance?
Starr: No, I don't know what you're talking about. What's that?
Ben: You've got to check it out. You've got to check it out.
Starr: Hamster dance?
Ben: I don't even want to spoil the surprise.
Starr: Okay. I'll write it down.
Josh: Everyone should check it out.
Ben: It is like the original internet video meme song catchy thing.
Josh: Viral video. Viral song.
Starr: Okay, I probably seen it, but... Yeah, I probably seen it, but all the new viral content has pushed out the old viral content. It's like a stack that just overflows. It's like a stack overflow.
Ben: Exactly.
Starr: They should name a website that.
Ben: So deep.
Josh: My question is do we actually want to check out any of these videos, because it'll be stuck in our head and our kids won't shut up about them?
Starr: No, probably not.
Ben: Come on, Josh.
Josh: Is this like the ultimate troll, Ben?
Ben: You're spoiling the surprise.
Josh: Is it like Baby Shark or whatever?
Starr: Yeah, this is funny. So it was Ida's birthday the other day and-
Josh: Nice. Happy Birthday, Ida.
Starr: Yeah. So we did her birthday party, and we gave her her CD player, and I got her a couple CDs. She's got like four favorite songs, and they're all wildly eclectic. So we got her a Jewel CD, because she likes Jewel's rendition of Twinkle Twinkle. And we got her a Bob Marley CD, because she really likes a Bob Marley song, and some weird country western CD because it's got a Rudolph Red Nose Reindeer on it that she really liked. And what was the last one? Oh, yeah. The Wiggles, just for fun. Yeah, so yesterday... So I was very strategic about this, because kids birthday parties are chaos. So I was like, "Let's open the CD player first. You get one CD, the Jewel CD, which is super mellow." So I was like, "Why don't we just play this while we open the rest of your presents." So we had this super mellow acoustic music playing, and it made it a little bit more chill. I don't know.
Josh: Did you have a lot of kids there or was it manageable number?
Starr: There were no kids.
Josh: Oh, okay. I was going to say.
Starr: She had her party at daycare-
Josh: Okay.
Starr: -and then at home we just did it with... because all of her friends were at daycare, so at home we just did-
Josh: That's genius, actually.
Starr: -an adult thing. By adult, I mean her parents and her aunt, and that's it. And then 1000 phones on FaceTime. A complete camera crew.
Josh: Well, good for you. I've never been... I don't know. The whole invite 50 parents to your house from school or whatever thing terrifies me.
Starr: Yeah, that's why we were like no we're not going to...
Josh: Yeah, I don't think I'll ever do that.
Starr: So what are we actually going to talk about, guys?
Josh: Yeah. I mean, I don't really care what we talk about. I don't mind if we talk about Heya, really. Yeah. I don't know.
Starr: So is Heya public at this point?
Josh: No, it's not. It's still private. We haven't actually talked about it.
Starr: So are we editing all this out?
Josh: I don't know.
Ben: I guess one question is are we ready to talk about Heya publicly yet?
Josh: Yeah, I mean, I don't care. I don't think like... I don't really... I wasn't going to make a big announcement of it anyway. I don't know. I've just been working on it.
Starr: Personally, I'm fine with just letting things drop. It's not like we're a public company and our stock price depends on things being released in a certain way. I don't think if... I think if we decide to just drop the project and not do anything all of a sudden again, I don't think anybody is going to really care or fault us or anything.
Josh: Mm-hmm (affirmative).
Ben: Okay. Let's talk about it.
Josh: I was going to say I haven't decided the license yet. So-
Ben: Let's talk about that.
Josh: -that's the main reason why it's not public.
Starr: Yeah. We could give a disclaimer and be like everything is tentative and nothing's real.
Ben: These are forward looking statements. Please do not make your investments based on the things we discuss in our podcast.
Josh: Yeah, don't by Honeybadger stock based on anything we're saying here.
Ben: Right.
Starr: So-
Ben: Yeah, let's talk about that.
Starr: This is like one of those... So this could be like one of those movies where half of it takes place in a alternate universe.
Josh: Mm-hmm (affirmative).
Starr: So this could be the alternate universe Founder Quest where we talk about this thing that Josh has been working on, or it could be your just mundane universe Founder Quest, in which just nothing's going on. We're just petting puppies, and drinking lattes over here.
Josh: You never know which is which.
Ben: Let's just go for radical transparency. Let's talk about it, and-
Starr: I'm into it. Honestly, I can't keep track of things that I'm not supposed to talk about, like I'll forget. All right, so I guess all that stays in, right?
Ben: Maybe.
Starr: Mostly?
Josh: If it does, this is the longest build up to I don't know.
Starr: Okay, that's fine.
Starr: Let's do a clean break just in case. I have no idea how they're going to edit this, since I'm not editing it anymore, but let's give them a clean break. So what are we going to be talking about today, guys?
Ben: I think we're going to be talking about Heya.
Starr: What's Heya? I don't know what you're talking about.
Josh: Heya's my super secret December... Well, it's longer than December, but I worked on it in December as my side project. Yeah, I don't know. It's a thing that we've thought about a lot over the last year or so, and it's something that we've wanted to play around with and try. So I've been working on it. I don't know if it's going to fly yet or not. We haven't actually started using it. But it's a little software project, and we can discuss what it does.
Starr: I know we've had some pain points around our communication tools that we use to communicate with our customers.
Josh: Yeah. I think we've talked about our frustration with Intercom a little bit on this podcast, as I recall.
Starr: Yeah.
Josh: I know... I'm trying to remember when this story would begin, because I know, Ben, you've got a lot of opinions about this too. And it's something that, I guess all three of us, but Ben and I especially have been ranting about for some time now.
Starr: Yeah. It was the Winter of 1997.
Ben: A very cold year, and I do have opinions. That's for sure. Yeah, I think we've talked about it, but it doesn't hurt to talk about some more, like how we hate the world. Specifically, spending money that we feel is not being well spent, and that's where we are with Intercom. So we've used Intercom for quite a while. We moved to Intercom from Help Scout when we wanted to have some chat functionality as part of our customer support.
Starr: So just in case people don't know, what exactly do Intercom and Help Scout do?
Ben: They help you have relationships with your customers by receiving inbound requests. In the case of Help Scout, that's primarily what it does. But also sending out communication to your customers, and Intercom has been very strong about that and Help Scout has actually picked up some of that lately.
Starr: Okay. So when somebody goes to a specific page where they sign up for a upgrade or something, you can trigger a message that gets sent out to people. That sort of thing.
Josh: Yeah. Yeah, and they all do different things. They handle different aspects of the customer communication life cycle, except for Intercom, which kind of tries to do it all. That's one reason that it's probably so expensive, but it's also another reason why I think that... It does a lot of things, and I think any product that tries to do everything isn't going to make everyone happy. So I think we fall into the camp of it does what we need but for too much money, and it doesn't make us very happy to use it.
Starr: I don't know about you, Josh, but I'm a happy Zoho CRM user.
Josh: Yeah.
Starr: I also use Zoho writer, and Zoho babysitter.
Josh: Zoho desktop.
Starr: Zoho, they come twice a week and clean out my house.
Josh: Yard service.
Starr: Yeah.
Ben: I heart Zoho. So we did move to Help Scout, back to Help Scout from Intercom several months ago. Josh did that for us, because we were not too happy with how Intercom was handling our inbound requests from customers, like support requests. That's been great. But we still have been hanging on to Intercom for outbound messaging. So particularly for life cycle messaging, like Josh mentioned. So when someone signs up, we send them an email. When someone maybe takes too long to install our client, we send them an email giving them a little nudge saying, "Hey, we see you haven't done X. Please go do X." And other automated sequence emails like that. So we're still using Intercom for that, and we're kind of to the point where we're frustrated and ready to stop spending as much money on Intercom just for that one feature.
Josh: Well, and the other thing... There's two things. So that's one of them. The other thing we use them for still is our broadcasts to customers. That's where you might think that, well, if you moved your support out of Intercom, and now if you're just using it for onboarding emails, you don't need to have tens of thousands of users in there necessarily. But for broadcast you do, because you need to be able to email everyone when you want to, or segments of people. And of course, Intercom, the pricing is based on how many users you have, so we're still... We're basically still spending the same amount of money on Intercom and paying for Help Scout now. And we're just trying to figure out how to untangle this whole mess so that we can have a single tool for each purpose basically.
Starr: Yeah, so broadcasts are like, it's like a mailing list, right? It's like the sort of thing that-
Josh: Just a mass email.
Ben: Like Mailchimp.
Starr: Yeah, like Mailchimp. But we used Mailchimp at one point for this.
Ben: Yeah, we did.
Josh: Well, we did and we used... We currently use ConvertKit for our marketing email. About a year ago, we had been talking about building some sort of Intercom replacement or killer or something like that that's going to solve the Intercom and the email marketing problem for us, and do everything in one tool and basically combine email marketing and customer lists somehow. And I think over the course of those discussions, I learned how bad of an idea that really is and went the opposite direction of where I'd really like to separate more features, even in Intercom, and have more single purpose type things.
Starr: A Unix philosophy for customer messaging.
Josh: Exactly. Yes. Yeah. Exactly. One of the problems with that, though, is especially if you're going to build a SaaS, like some sort of centralized tool that is going to do this, is the user database, because all of these things need to have access to your users and access to the information you use to create segments of people for various purposes, whether it's for emailing them directly through a broadcast, or if it's sending automated sequences to certain groups of people. So I think that's one of the reasons why Intercom has been so successful is because it's really difficult to do that and to duplicate your data and send it somewhere else in the first place.
Josh: So if you only have to do it once, and that one thing does everything else-
Starr: Yeah, so like-
Josh: -then it's good.
Starr: So right now... Yeah, right now basically we've got two copies of our user data. We've got one copy that is the real copy in our database, and then we've got this sort of second ancillary copy in Intercom. So every time a user updates themselves or we have a new user sign up, we have to send that information to Intercom as well. And we have to keep those in sync, which is just a fun thing to do.
Josh: Yeah, there's whole industries that are building up just to solve that problem.
Starr: Oh, really? I didn't know that.
Josh: Which we can talk about. Well, I mean it's part of the-
Starr: I'd love to talk about that.
Josh: It's part of the overall, I guess, what do they call it? Is it martech industry?
Ben: Mm-hmm (affirmative).
Josh: So that stand for marketing tech. But I think the biggest player in that is probably Segment, which is a data warehouse tool, which you send your data to it, and then it's the central location where it basically broadcasts it to all your other tools, marketing, customer communication tools that need it. And that solves that problem of using a bunch of things but only wanting to send your data, handle sending it to one service versus 10 or something.
Starr: Yeah.
Josh: So it's just the more tools people add to their stack, the more complicated it's becoming. It seems kind of crazy.
Ben: And the more expensive it gets, because Segment itself is not cheap. So we're in the position where we're paying Segment to send our data to Intercom, and we're paying them to send emails to our customers, and we already have all that data in our own database. So we thought, man, we got to do something about this.
Josh: And meanwhile, we're not that big. We have one person who does marketing full time, and then four other people in the company that do everything else. And it seems like we've got this enterprise level marketing stack that we're basically using just to email a handful of people.
Starr: Yeah, I feel like in a larger company they would probably have somebody who just did the Intercom integration, and just made sure that was perfect.
Josh: Well, yeah, I think... Yeah, in the larger companies they've got both, multiple developers, I imagine, dedicated to managing the integration side, or maybe maintaining that Segment integration, and then they've got marketing teams that are also working on from the Segment onwards side. That's the benefit of Segment. One of the benefits is that a relatively non-technical user can go into Segment and add a new tool and copy paste some API keys or something, and it's basically added to your marketing stack automatically. So it allows non-technical teams to add tools to your website without going to the developers.
Starr: What you just said, Josh, is literally giving me hives right now, and I'm thinking about GDPR and compliance things.
Josh: Right?
Ben: I was thinking the same thing. It's like, yeah, and then all this data is flowing everywhere, and we're tired of that.
Starr: Even the lowliest marketing intern can make your company violate GDPR now.
Josh: Okay. So we're going to do a jump cut, and it's like meanwhile in Sacramento.
Ben: CCPA.
Josh: Right. So meanwhile, you've got all these... privacy and regulation is the thing of the day. It just seems like these two trends are... I can't decide if they're actually complimentary to each other or if they're going in opposite directions. I think that it's a little bit of both sometimes. But yeah.
Ben: I mean, the good news is companies like Segment and Intercom, they have good compliance policies in place. So they're good stewards of your data. I don't distrust them, but at the same time it's just yet another thing you have to answer, another thing you have to put a control in for, another thing you have to worry about. It would be good to have all our data in one place.
Josh: I mean, we're not going to get into a political discussion here, but the answer to regulation and centralization in this case, if you have one data warehouse and they are compliant, and then they implement integrations that are compliant to the next party, which is like Intercom or whatever, then that solves a huge problem for you, if you're a large company that wants to use a bunch of tools without having to have your own compliance team that's managing your DPAs or whatever and having to update everything every time you use something.
Starr: I mean, you still need to get, in the case of GDPR, don't you still need to get the user approval though? Like if you're sending your data to Intercom, and then you suddenly start sending it to Help Scout as well.
Josh: Yeah, I think you do, and I don't have... I'm not an expert on any of this, but my feeling is these tools are also going to, like they're going to help with that too. Centralizing all this stuff, if you're going to go the route of using a bunch of, using everyone basically... This centralized architecture probably will help with that, but someone will make a tool for it that will help get that consent. But it's also a lot more complicated and potentially not actually protecting user privacy either.
Starr: Point of order, Josh. Point of order. I just want to say you say you're not an expert, but the very fact that we have a podcast makes us experts at whatever we talk about.
Josh: Oh. Yeah. You're right. Yeah.
Starr: That's how it works.
Josh: I've got this... There's this book on... it's like a book on law, like a law course on my Audible account that I've got on my to read list. So after I read that, maybe we can come back and revisit some of this stuff, because I'll basically have a legal opinion.
Starr: That's awesome. Then we can stop paying so much money for that attorney.
Josh: You don't have to congratulate me yet.
Starr: Congratulations, Josh.
Josh: But give me a month or maybe two weeks or so.
Starr: What is that? (singing)
Josh: Got my graduate cap on.
Starr: Yeah, we'll get you a graduate cap for next time. Oh, my goodness. So you know what would be very convenient for GDPR and all sorts of regulations? What would be very convenient is if you didn't have to send your data anyplace but your own, well-secured, encrypted at rest, data store. If only there were a solution-
Josh: Which we already have, right?
Starr: If only there were a solution that allowed you to message your users using your own data store that you have locked down and you control, I mean, that'd be incredibly convenient, because then you wouldn't have to duplicate your data everywhere. You wouldn't have to worry about as much compliance stuff. I don't know.
Josh: But wait, wouldn't it be...
Starr: Should really think about that.
Josh: I mean, where would we find such a data store, though, because it's going to add a lot of overhead to manage our own data store, I would imagine. I don't have any idea where we're going to find such a thing.
Starr: We'll get Ben to do it.
Josh: It's not like we already have a database where we store our users or anything.
Ben: We actually might have one of those.
Starr: Wait, we have one? I think we're at different points of the sketch.
Josh: Oh, okay. Yes, we have... there's such a thing as a database, and most people have one, which is the conclusion that I've come to.
Starr: We're advanced because we've actually got a couple of them, I think.
Josh: Right. In a lot of cases, that's the issue. The more times you duplicate your customer data and have to sync it different places, the more complexity it adds to your system and to your data. Not to mention the more, like with anything else, it locks you into things, because if you ever want to change that data format, you've got to figure out how to update or migrate it in a bunch of different places instead of one and re-sync it or however you're going to handle that. Yeah, so the approach that, the idea that I've got or that we've had and the direction we're trying to explore is basically can we build tools that basically just use our existing user database? To where we don't have to sync that data to other parties.
Josh: Ideally, this is going to be something that is self-hosted, so we don't have to deal with the privacy and regulation constraints and problems that arise when you have to add a new third party to your stack. So that's kind of the direction that we've gone with this set of problems that we've been describing. That's kind of what Heya... Heya is a project that addresses some of this stuff, specifically the sequence emailing.
Ben: Yeah, not to mention we'll save ourselves some coin.
Josh: Yes. It's cheaper just to send emails versus use an entire marketing stack.
Ben: Now Josh at Baremetrics he says, his opinion is you should never build something internally that you can just buy from someone, right? He's all about use the vendors that are out there, like it doesn't make sense to pay a developer to build something for you.
Starr: Where's the fun in that?
Ben: Totally. But I get where he's coming from. It's like, you know, if that's not your business then it doesn't make sense. But I think in our case, A, we're developers and we love building stuff, so we're just not going to stop, so hey might as well, and B, I think the end goal here is to not only to build something for ourselves that we feel like we love, but also that other people like us will also love. And then we just make bank selling that to people.
Josh: Yeah. I think it all depends on what it is that you're building. I mean, I think as a rule it's probably good to say...
Starr: Oh, the bomb's going off.
Josh: Sorry, my phone. I think generally as a rule it's probably good to say we're not going to just build everything that we use. But I think there are cases where, I mean, it could make sense.
Starr: I feel like we just-
Josh: It all depends on what the use case is, what the benefits are, the trade offs.
Ben: And hopefully this is one of those cases where it makes sense, because we're definitely doing it.
Starr: Yeah, so this is... I feel like we kind of slid into this, talking about this, so let me just catch people up.
Josh: We haven't really said what it is.
Starr: Yeah, so if it is okay if just go ahead and do that?
Ben: Go ahead.
Josh: Yeah.
Starr: For the past couple months Josh has been working on a little side project, a little but not uncomplicated, as he's learned, I guess. And the goal of that is to provide some of these marketing messaging features that we currently use Intercom for, but to do that in a way that pulls the data directly from our own databases and runs on our own server, and that we have more control over. Did I do that justice?
Josh: Yeah. I think so.
Starr: Okay. Cool.
Josh: Yeah. And what it is, is... So we're building as... it's a Rails engine. Our platform is Ruby on Rails. So it basically just plugs into our system, like you said. And currently we have a bunch of things that it possibly could do, or different things that we could solve. But right now we're focusing on the sequence. Basically, we're trying to replace what we're left with at Intercom, because that's obviously the goal that started all of this was to solve the email sequences and potentially we need to have a way to broadcast, like send a mass email to our users. So that's kind of the MVP for us. When we can leave Intercom is when we have those two things. Currently we have the sequencing completed.
Starr: So what does the sequencing entail?
Josh: The email sequences are, I call them campaigns. But they're basically just drip email campaigns, like similar things that you'd see in a lot of other customer communication products, or like user onboarding basically. So what they allow you to do is run user onboarding email campaigns. So when someone signs up for Honeybadger, they get a welcome email. They get instructions on how to install our code. They get a bunch of other things maybe based on... like throughout their two week trial that they go through, they might get emails prompting them to set up features that they have not actually looked at or set up yet. So it's got some rules built into it where it can say if someone hasn't used this feature, send them an email. If they have already used it, then don't send them an email, because they've already seen it.
Starr: How cool. So it's sequences, but it's not just time based sequences. It's got some logic built into it.
Josh: Yeah. So it's based on time and logic to determine. So really it's still like a time based sequence at its core, but basically where the logic comes in is it allows you basically to skip emails, or if you look at it the other way, you can send emails if they match conditions. But really it's still based on it's going to send a sequence of emails, but if they happen to not match the conditions for one, it'll just skip it basically.
Starr: Okay. That's really cool. I don't know. Should we talk about sort of some of the things that you've learned from doing this? I haven't done any of it.
Josh: Well, we can talk about... I think one of the cool things about this is that because we happen to be developers who like marketing to varying degrees, we are able to build this in a way that appeals to us as developers, and not necessarily to marketers, or at least a segment of people that have an interest in both. So one of the things that I've done with it is so far it doesn't have any kind of graphical user interface. The user interface that it does have is basically Ruby code. So to actually set up these campaigns, the way that you do it is very similar to generating a user model or something, or mailer in your Rails app. So you can generate a campaign. It basically creates a file on disk in your project. It's a Ruby file with some boilerplate, and it lets you define what your sequence is or what your campaign is.
Josh: And from there basically you just... a lot of the hosted tools have automation features so that you can set up rules of when people should join a campaign, or when they should leave, and handle a lot of the other life cycle things that happen around these email sequences. But in our case already have an awesome tool, which is called Ruby on Rails, that has all kinds of callbacks and event subscriptions, and all kinds of things that we can hook into basically to just add people to campaigns. So at its core it's a lot simpler, because really you're just adding people to these campaigns, removing them from the campaigns, or if they complete one it automatically does that for you. So in a lot of ways it's actually simplified a lot of things for us.
Starr: Oh, cool. So you don't have to have a lot of that functionality duplicated in a external service.
Josh: Right. Yeah. That's kind of the idea. The way I look at it is, I mean, Rails has a lot of automation stuff built into it. It does a lot of similar things that marketing automation tools do. But it's for developers, and it's a lot more flexible. So we can take advantage of some of those things. Of course with the caveat that it's a much more technical tool. We're not going to have a completely non-technical user, at least not yet, step into this and manage it.
Starr: So if we really want to target technical users, shouldn't we have the configuration be done in Haskell? Then people could just get their Heya set up.
Josh: Right yeah. I did evaluate Haskell versus Ruby and spent a lot of time debating if I wanted this to be functionally pure or not, but I decided that in the end that Ruby is actually pretty flexible. It's already kind of a automation scripting language-
Starr: Yeah.
Josh: -for a lot of things. So yeah, I went with Ruby.
Starr: That's cool. That's a really... I think a lot of people don't know this that it's actually kind of neat, is that Ruby is, in Japan at least, it's used for a lot of automation things, a lot of... they actually use it for some embedded stuff, like I forget what car maker, but some car maker a while back used it in the embedded systems in their car. So Ruby actually isn't terribly suited for stuff like this, and it has a bonus feature that, unlike Haskell, we can actually use it.
Josh: So yeah, Heya though, the status of it is that I have a limited, like a feature set that I thought I needed basically in order to completely replace the email sequencing that we do in Intercom, and that is currently feature complete to the best of my knowledge.
Starr: Oh, yay!
Josh: It's going to require a little more testing. We haven't actually used this in production yet or anything.
Starr: Awesome. Hey, wait a second. Wait a sec. Wait one second. They can edit out this pause. Don't say anything interesting. I'll be right back. Hold on. Okay.
Josh: Okay.
Starr: Take off my headphones. This is very exciting.
Josh: He's got like a noisemaker or something.
Ben: That's what I was thinking. Yeah, he's going to get the party favors.
Josh: Nice. Hooray.
Ben: Hooray.
Starr: We have those left over from the birthday party.
Josh: Love it. Yeah. That's like a party noisemaker.
Starr: It didn't sound like a strangled duck to you?
Ben: We had to put that in there for the hearing impaired folks. We got to put that in the transcript.
Josh: No, it's not like a dying elephant.
Starr: Yeah, that's the problem with these. They're a little bit cheap. So we're just, at the party, we all just sounded like a herd of dying geese or something.
Josh: Can you do me a favor though? You need to keep that by your podcast station for future episodes.
Starr: Is this going to be like my Kramer sound effect?
Josh: Yes.
Starr: It's going to be like bye, bye, bye. I'll just have my... Okay. I'm going to get a collection of these things. I'm going to be so obnoxious.
Starr: Okay. We'll see.
Josh: So we're kind of at the place where I think we can try some of this code out. I actually have a branch that I was showing Ben of our main Rails app that adds our onboarding emails using a... to our Rails app. Aside from doing some testing and maybe some additional set up work for actually sending the emails and that sort of thing, I think it's close to being ready to go.
Starr: That's awesome.
Josh: Now if I sound hesitant it's because every time I think it's ready to go, I find some sort of edge case that invalidates all the work I've done to date-
Starr: Oh no.
Josh: -and I have to figure everything out from scratch, but I'm pretty sure at this point I've spent enough time on the actually scheduling logic, where I think that it's ready to go.
Starr: Yeah, you've had to do some intense SQL querying and stuff, right?
Josh: Yeah. It's because I'm basically using... The little project, like the software itself, it's a relatively small project. I don't know how many lines of codes it is, but it's not a ton, and most of the complexity, though, is in SQL. So it's mainly a SQL program is kind of the way I look at it. It's like a SQL program with a little code UI built on top of it, or some framework built on top of it. But yeah, it took me a while to get the SQL and basically the test suite that proves that the SQL does what I think it does. To get all that to work was kind of the meat of the project.
Starr: Well, there you go. So you're not actually building this in house. We're using SQL.
Josh: Yeah.
Starr: So we meet Josh Pigford's rules then, I guess, because we're not wasting resources by building something in house we could buy.
Josh: Yeah, that's true.
Starr: And it's even free, right? We're using Postgres. It's free.
Josh: Or if you want to look at it the other way, it's going to save us at least 12K a year in Intercom bills.
Starr: That's a lot.
Josh: I think I've probably already blown that budget, if I'm being honest, but that helps lighten the load a little bit.
Ben: Yeah, I think maybe the beginning, the initial desire for this was to save the money on Intercom, but I think in reality the other reason, we're developers and we like building stuff. I think that's really what has been the driving force behind this.
Josh: It's not the money. Yeah. I don't mind spending that 12K on Intercom, especially if I was happy with it and it didn't give me any grief. I'd be fine with it. Like, was it Josh that says just buy tools that are already on the market. But I think I was bored. This is something that I thought a lot about. I just wanted to see if it could be done.
Starr: Yeah.
Ben: It's like a really nice suit. There's nothing wrong with buying a suit off the rack, if it works. It'll get you to the wedding. It's all good. But when you want to feel really good, you go and you get that custom made suit, and then you're on top of the world.
Josh: Right. Yeah.
Starr: Do you have a custom made suit, Ben?
Ben: No, not yet, sadly.
Starr: Oh. Oh, man. Well, if you ever want one, I know a guy. So what you're saying is you're doing it for the love, Josh.
Josh: Yeah, the love and the adventure, I guess. I think the whole project has actually helped me work through some thoughts and opinions or ideas I have about marketing automation and developers doing marketing automation. So it's also been kind of like an intellectual exploration to some extent, trying to figure out if there's other ways to do things. I don't know if anything will actually come out of that, but it's been an interesting project in and of itself. So if it came to nothing, I'd still be happy that I did it, I think, is what I'm saying. And also this is one of our side projects. Last year, we've tried to do more things where if there's just something that we wanted to build, we've tried to give ourselves time to actually just go do and explore that thing. That's one of the things we did in this last December was part of our winter break was go and work on your side project.
Josh: So I know we've got, what, like three or four other side projects that have been happening in the company that I don't know anything about, because we haven't actually.... this is the first time we're actually reviewing what we did. So I'm excited to see what everyone else has been working on. But this is mine.
Ben: Yeah, we're getting together next week, all of us, and I'm definitely going to be talking about the side project I worked on, and we'll get some reports from Ben and Kevin. But I'm looking forward to having more Heya around.
Josh: Yeah. Yeah, me too.
Starr: Have we made any decisions about... I'm sure people are just chomping at the bit. What should they do? Should they tweet at us? Should they... This isn't released.
Josh: Yeah, it's not released. I don't know when it will be released. I guess the biggest factor is we haven't decided what our license is going to be yet. So we'll be talking about that. Obviously, we can't really release it without a license. But the other thing is that it's so early it just became kind of even... the MVP or whatever just became feature complete, and we haven't run it in production. I'd like some confirmation that it actually is going to work for people before they trust all of their emails to it, or their customer database to it. So I'm a little paranoid in that regard. But yeah, I think we should probably get it released pretty soon, and I'd like to just to get it out there.
Josh: In the meantime, I'm interested in hearing if any of this actually appeals to the developer/marketer or marketer/developer out there. So you could always tweet or email us or whatever.
Starr: Yeah, you can tweet at us @FounderQuest.
Ben: And I think, get in touch too, if there's something that you've always wanted in an email tool, a customer messaging tool that just doesn't exist out there, or it exists but it's not quite right, something that you would like a little different. I think this is a great time for us to find out other use cases besides just our own.
Josh: Yeah.
Starr: Yeah, tell us your heart's desires.
Josh: Right. I mean, that could relate... I mean, obviously Heya's going to be something, for now at least, specifically for Rail users. This is a broader problem space that the three of us have spent a lot of time thinking and talking about. We're interested in it. We're not diving into a new market head first, but yeah, it's a hobby of ours for sure.
Ben: More to come.
Starr: More to come. Well, awesome. And I'm looking forward to seeing the Haskell version, because I won't understand-
Josh: Because you really like parentheses?
Starr: I like looking at Haskell knowing that somewhere there's somebody that understands it.
Josh: Yeah. You're just like, "I need more nesting in my code."
Starr: Yeah, I want to live in a world where somebody understands Haskell. All right. Well, do we have anything else we'd like to mention about Heya?
Josh: I don't think so.
Starr: Oh, wait. Wait, wait. Yeah so, you always do such a great job at naming things, Josh, so is this... It's obviously like, hey, we're emailing you communications that you've definitely opted in for and are looking forward to receiving. But it also a reference to that song?
Josh: It's not but it can be. We've talked about that after the fact. So I think that it's both at this point.
Starr: Okay.
Josh: I love... Yeah, that's a great song. You're talking about Hey Ya, right?
Ben: We'll have to get some info from them about licensing it for our theme song.
Josh: Yeah. That's the only problem. We don't have the licensing yet.
Starr: I mean, fair use, I think you can use a couple seconds.
Josh: Really?
Starr: Yeah, I think you can use a couple seconds.
Josh: All right. So we can splice that in, right?
Starr: Maybe. We'll see. We can splice in my acoustic version. I'll send it to the editors.
Josh: Nice. On the party...
Starr: On the xylophone. My acoustic xylophone version.
Josh: You got to play it on the sound maker from Ida's party.
Starr: Oh! Of course, yeah. It's a little monotone.
Josh: Basically just use it like a kazoo.
Starr: Yeah, maybe. We'll see. We'll see. Anyway. All right, so if we're done, if we said everything we're going to say, then I would say I'm going to give our spiel. So if you are interested in writing for our blog, we're interested in maybe talking to you. If you write about technical stuff and you want to check it out, we have a write for us link in our blog header. Please... Oh, my goodness. Somehow we got added to some list of people who just, I guess, buy content, and so we get all this spammy terrible people contacting us. Somebody wanted to have guest posts on our blog about growing cannabis and stuff. It's like, what? You obviously did not read the write for us page that is accessible from the top nav in our blog. So yeah, anyway, if you are a decent human being and you want to talk to us about writing for us, go check that out. And if you want to give us a review, we'd love that on iTunes or Apple Podcasts or whatever they call it.
Starr: So that's all. All right. I'll play us out. This is my rendition of Hey Ya. All right.
Josh: Nice.
Ben: That's awesome.
Starr: Thank you. See y'all later.
Josh: See you guys.
