Scaling Buzzsprout: A Deep Dive into Podcast Hosting, CDN, Rails, and Business Happiness with Tom Rossi

Speaker 1: 0:00

This is remote. Have you any remote ideas to the meaning of the word?

Speaker 2: 0:08

Day three podcast. Good morning.

Speaker 1: 0:10

Hey, andrew, good morning, we're halfway through Andrew.

Speaker 3: 0:13

what is it?

Speaker 2: 0:14

7 o'clock for you in the morning, 7 o'clock in the morning. Had we not recorded right now, what time would you have gotten up? I was up at 5. Okay, that's what I thought. Take a long time to wake up because you look like you're still asleep and you've been up to the mountains Because.

Speaker 3: 0:26

I didn't get breakfast yet. I've had the busy week. It's been one of those weeks. Okay, in fact, the fact that y'all scheduled seven podcasts this week.

Speaker 2: 0:36

Six.

Speaker 3: 0:36

It doesn't matter. Seven on top of a re-fraw. It was kind of my fault, it was your fault, I blame you.

Speaker 2: 0:43

Like our recording link, you still only have one slot and I was like, well, that kind of sucks because, like, we recorded a lot of people on the west coast or in Europe, or so I was like I'll open up some more slots and then I forgot to trim them down. Yeah, they filled up in one week. So here we are. If we do this successfully, you won't have to record a podcast for two months. See, that makes me sad, but you still record. We could just get two months ahead, but then it'll be like, hey, rails 8, let's talk about the new features, and then, six months later, releases. That is it.

Speaker 3: 1:12

I won't get to see y'all smiling faces every Friday. That's sad.

Speaker 1: 1:16

That's important, you'll see me.

Speaker 3: 1:18

I'll have to break something in podium to force Jason to talk to me every Friday now. Yeah, then you'll see my frowning face If I turn my monitor upside down, which? I can do on the swivel board let's dig into it.

Speaker 2: 1:30

So one of the highlights for me at Rails world was getting to record a live podcast with our guests but with y'all and the company that made that happen is Buzzsprout, and there is a fantastic booth. You can find pictures of it online, of us recording and stuff in it. We got the episode back yesterday with Adam and it sounds great. So, yeah, it was a lot of fun and it really added to the conference experience for me. The person behind Buzzsprout one of the people behind Buzzsprout is also one of my favorite humans in the whole world. We met Tom last year Andrew and I did at Railsass and I immediately thought if I could have the like positivity and energy Tom has, like my life would be like 60% better. So I'm really excited today to have Tom Rossi from Buzzsprout join us. So hello, Tom.

Speaker 4: 2:25

Hello. Wow, that's high praise, it's true.

Speaker 3: 2:29

So we're awesome. When we met you at the Railsass. I remember meeting you at the roof and like, this is a cool human being.

Speaker 4: 2:35

Thanks. That was a really cool event. I loved just being able to spend so much. I feel like we had a lot of time to be able to hang out. That rooftop was pretty neat.

Speaker 3: 2:42

Yeah, super cool.

Speaker 4: 2:43

Cool vibes Did I pronounce your last name, right?

Speaker 2: 2:46

Rossi, rossi. Yes, I love your hosting names. Tom, if you don't mind real quick, maybe just giving a quick kind of intro overview of who you are, then we'll dive in Sure.

Speaker 4: 2:56

My name is Tom Rossi. I'm one of the co-founders of HirePixels. We are a product company, and we're most known for our product, buzzsprout, which is our podcast hosting service that we launched probably in about 2008. And we dreamed of a day that maybe it would be our biggest product and became that. Let's do. I think cereal and Apple putting the podcast app inside of the phone. Podcasting has just been huge, and so that's the product that we really spend most of our time on.

Speaker 2: 3:27

That's great. Yeah, we, as of an hour ago, are recent Buzzsprout converts, that's great, that's awesome, yeah, loving the platform so far.

Speaker 2: 3:36

So in the migration was really easy, which, as we were talking about before, we recorded it was like something I was nervous about. So Chris did the migration, but sort of click a button and then even this morning, like we had an episode on our old one, it was like, hey, do you want to see if there's any new ones and just migrate those to you? I don't know, everything was really well thought through.

Speaker 4: 3:53

So it's great. That's great Buzzsprout. We really wanted to be as simple for podcast hosting, make it as easy as possible for podcasters to be able to get into it. They don't have to have a big production team, they don't have to be very technical, and that's really where we started and continue to be today, even though we've launched all kinds of. There's so many features now inside of Buzzsprout, but we've still really worked hard to maintain that simplicity.

Speaker 2: 4:19

We talked about it before we started recording about Diving in with Rails, but I feel like now is actually probably a good time to go ahead and get a little history on Buzzsprout. So you mentioned Buzzsprout launched in 2008,. But you also mentioned you have a company that builds products. So what were maybe some of the things you were doing before Buzzsprout and were they in Ruby? How did you get into Ruby? Things like that.

Speaker 4: 4:38

Sure, we originally were a client services company, so people would hire us to build product for them and so we'd have a team and you'd respond to an RFP, you would write requirements, documents and you would go back and forth with your customer and all that kind of stuff. And everything that we did back then was in ASP. I think we started in regular straight up ASP and then eventually got into ASPnet and I got less and less technical and spent more and more time on the hamster wheel of sales. And then that business kind of blew up in around September 11th. Everyone froze their budgets. Nobody wanted to spend any money. Everything we did was a capital cost that no one wanted to incur when the markets were so unsettled. And so we said, okay, we got to do something and we built our first product and really it was just to keep the team busy. But that product grew over time. That product was called M-Sites was a content management tool. It was originally built in.

Speaker 4: 5:37

Microsoft continued to grow. I could not even code it right Like, oh, I was just a sales guy at this point. Some years later it got down to just me. The team just dwindled down until it was literally just me and a server running this product. But the product was growing every month and I was like, man, this is such a better business than the business we had been in before. So a buddy of mine, I was telling him about how great it was and he was like, hey, I got an idea for a product. So that was our second product, this product called TIC, which is a time tracking application. And he said, before we do this, can you just watch this video, can you just check this video out? I know you're a Microsoft guy, but can you watch this video? And so he sent me the famous DHH how to build a blog video and it addressed so many of the issues that we experienced when we were building applications before. And it was so much easier. And I was like, look, if I'm going to have to learn coding, I would much rather learn and go back and learn Rails thanNET. Of course, I was still on a Microsoft computer and had all those complexities, if anybody's ever tried to do that. So then we built that first product, tic, using Ruby on Rails. I mean it changed our lives, literally like it changed our lives, because now we were able. It was just two of us.

Speaker 4: 6:46

He came on as my partner and we built TIC, and really it was two of us. We already had two products, right, because we had the M-Sites product and we had TIC. Then the next product that we built was Buzzsprouts. We had tons of people on our M-Sites platform that wanted to be able to host audio. So M-Sites we ended up having a lot of churches that were using it because they wanted a blog and a photo calendar and all these kind of things. This is before Facebook, and so my partner was like we should build that as a separate product. I was like I don't know, you think anybody would pay for that. So Buzzsprout was actually built as a hosting platform for those customers that we already had, for them to be able to upload their sermon audios. And we launched Buzzsprout in 2008 and it was kind of a fun project. It was always fun to work on, but TIC was really the thing that was paying our bills the time-tracking app and so that was what we spent most of our time on.

Speaker 4: 7:35

We launched several other products. We have a product called Streamcare, which continues to run today, which is a very specific product related to workers' compensation pharmaceuticals. So we just kind of fell into that with a friend that needed it and we were like we'll build it. We'll build it as a product. We're not going to do client services work for you, but we'll build it and charge a transaction fee type thing. And so we still run that product. We have a product called Donor Tools, which is donor management for nonprofits.

Speaker 4: 8:01

I mean, we had more products than people, and that's what you can do with Rails, right, Because you had Kevin and I and we had multiple products, and since then we made an intentional push to grow the team. We're like you know what? Can we bring more people on to the team and have a real life-giving organization? Can we have a company that we can share in some of the things that we've been able to experience as the founders, as the people that actually started the company? Can we share that with the team? And since then there's about 20 of us, about 10 on each side, 10 people on Buzzsprout and people on stream care. Most of that is support. On Buzzsprout we have four Rails developers, a couple designers and then mostly support.

Speaker 2: 8:43

That's awesome, it's a lot of products. Yeah, for a lot. One team, that's awesome. I'm curious are M-Sites or TIC or either of those still running, or yeah, yeah, okay.

Speaker 4: 8:52

TIC is still running M-Sites. We actually shut it down. So we started M-Sites in 2001 because that's when we started development. I think we started having customers by 2002 and we just shut that down last December.

Speaker 3: 9:05

Oh, wow, so it was a year ago.

Speaker 4: 9:06

Finally, I was like, I told them. I was like you guys have to go. So I'm sorry, but it's not even safe for us to running the server, because it's just we couldn't keep up, we just couldn't get it running and so, yeah, so we ended up shutting that down. But TIC still does well. We keep it secure and continue to support it, but we just don't roll out features for it. That's cool.

Speaker 2: 9:27

So TIC was your first Rails app. Yes, what version of Rails was that at the time when you started?

Speaker 4: 9:33

I want to say it was either Rails 1 or Pre-Rails 1.

Speaker 3: 9:37

It was your OG.

Speaker 4: 9:38

Yes, it was OG, we actually went to Chicago and met with the Basecamp team Back then. They had a little workshop that they did at the local university and it was a getting real workshop and it was hysterical, coming from client services, where you wrote requirements, documents and you had a map of all the things that you were going to build. And they're like throw all that out and totally rethink the way that you build. And so we're in there and it's just challenging every conception that we had about how to build a product. And Kevin, my partner, and I we were like, okay, we're just going to do it. We're just going to do it exactly the way they said. We're going to fight our instincts and we're going to do it the way they did.

Speaker 4: 10:17

And that's what we did with TIC and really I mean it changed our lives, not just the framework I love writing beautiful code but also the way that we approach. I mean the Rails opinion plays into how you approach your product and how you build features and how you sell and position your product, and so it really has. That's why Railsworld tying it back to Railsworld, that's why Railsworld was such a great opportunity for us. We've received so much from the Ruby on Rails community looking for any opportunity to be able to give back, and the Rails Foundation and Amanda specifically. Like what she put together was such a great package. It just fit exactly who we are to be able to give back to the Rails community because of the impact it's had on us, that's awesome, but I am curious you mentioned TIC doesn't get new feature updates, being such like a early Rails app.

Speaker 2: 11:04

What version do you have it up to now?

Speaker 4: 11:06

Wow, yeah, that's a good question. Tic we brought up to, I believe, rails 6. So we didn't make it 7. Yeah, respect, respect. Otherwise it's just too painful, but it is on an older version of Ruby, I think it's 2.65. And so we're having some issues. We don't typically work in Docker, but we're looking at setting up a Docker and then we're going to, in the process actually of upgrading, to get that to a more stable version of Ruby so that way we can run it locally. If we want to go touch things, we want to be able to go do that. That's really cool. It's been out for so long, it's so stable. It's not like you've got a lot of bugs or anything, but you just want to be able to go and run that code.

Speaker 2: 11:46

Yeah, and if you do need to make a change. You don't want to upgrade to Ruby 3 and then introduce bugs that you didn't have before. Just because, you upgraded. I'm really impressed by that. It'd be amazing if they got to 3, like Rails 3. So Rails 6 was double my expectations.

Speaker 4: 12:04

Yeah, no, we were still actively developing on TIC when we went to Rails 3. Tic was our primary product, really until about 2014. It was kind of what we would do is, from work cycle to work cycle, we would choose what features we wanted to work on. Hey, let's work on Buzzsprout this work cycle, or let's work on TIC this work cycle, and so we would go back and forth. But then, about 2014, we said look, I think podcasting is where it's at, let's just go all in on Buzzsprout, and that's the only thing that we built features for. And every once in a while we would go back and we messed around with that donor tools product, because that's a fun product for us to work on. It's the latest Rails, it's Rails Edge. Everything was built Greenfield, knowing what we had learned from all these other products, and so donor tools is a fun product for us to go work on and experiment with.

Speaker 2: 12:46

That's awesome. So building a podcast hosting tool. Andrew mentioned this before the call. Something he'd be interested in knowing about is what are some of the edge cases or things that you've run into that people might not expect when building a podcast hosting platform?

Speaker 4: 13:02

I feel like there was this lesson that we learned. I told you guys about the when we went to that workshop in Chicago and it's so funny, it's like embarrassing to think I was sitting at a table with DHH at lunch or something like that, and again coming from a Microsoft SQL server background, coming from naming all your fields and your database, like I was a database snob, and I'm sitting next to him and I said something like you use an integer column for your ID, what's going to happen when I have millions of customers? And David goes, do you have millions of customers? And I'm like no, that'll be a great problem to have on it.

Speaker 4: 13:36

That's true, kind of a mantra to this day that we say that'll be a great problem to solve, that'll be a great problem if we have that problem, but instead I haven't even built a product yet and I'm worried about when I have millions of customers. And so with Buzzsprout, when podcasting really started to explode, when really started to take off, all of those quote great problems happened, all of those that'll be a great problem to solve in the future. Well, those all hit.

Speaker 3: 14:01

So I was asked when base camp went down for a day because, of the integer column. How did you feel?

Speaker 4: 14:09

Yes, yeah, I did not say anything, I didn't point that out, but yeah, it's funny.

Speaker 3: 14:14

Just twirl your mustache. She was like yes, I foresaw this, I should have just tweeted.

Speaker 4: 14:19

That's a great problem to have. It was something like that, but yeah. So when Buzzsprout really started to grow, we started to run into all those issues. So remember, caching used to be pretty painful before. Rails made it really simple with Russian doll caching and things like that, and so we had very little caching. We had no CDN, so we were just exposing those MP3s. Originally we had them on our server and then we started. What we would do is we would host it on our server for about 90 days and then we would move it into S3 as kind of an archive and over time. That's just crushing and expensive. We actually had a case where 2010, 2012, somewhere in there, we had a podcast that went viral and it was a soccer podcast and it was called the Men in Blazers. I'll never forget. So Men in Blazers was a podcast. Now at the time, we're charging $9 a month. This podcast goes crazy. I guess they get picked up by NBC or something like that.

Speaker 4: 15:13

Next thing we know we're at the office. A couple of us were like hey, is everything slow? Yeah, everything seems to be a little bit slow. Then we get a phone call from our hosting company and they're like what are you guys doing and we're like what are you talking about? You're crushing all of our bandwidth, we're going to shut you down. And then they get a phone call our hosting company. We were working with a company called Rails Machine. They get a call from their hosting company and they're like you're crushing our bandwidth, we're going to shut you down. Next thing I know they shut our bandwidth off.

Speaker 4: 15:38

So like our server is down, we're rapidly trying to figure out what to do. We end up having to shut down Men in Blazers to get everything restored and the bill that month it was like over 10 grand for this $9 a month account. We're like, okay, we're going to have to figure this out. Like we're going to have to figure out how to scale Buzzsprout. And so at that point we started moving everything into the cloud, everything into S3, and started to build that out.

Speaker 4: 16:02

But we still didn't even build out the CDN for some years later, when the bills just got so expensive. That was a really big project to be able to start putting things behind CloudFront and then eventually Cloudflare and then Active Storage came out and Active Storage doesn't really play well with CDNs and public assets, and so we've got tons of monkey patching that we have carried forward and we're actually in the process right now of removing a lot of it, because there's some things that you can do now with Active Storage to make things better. So there's less monkey patching, but still monkey patching for the CDN that's probably one of the biggest was introducing caching, scaling our servers. We moved to Kubernetes and that just gives you the ability to scale it out. So now if a podcast goes big, it really doesn't do anything. That matters is your bill.

Speaker 3: 16:48

So whenever this episode blows up, we'll know that the Kubernetes clusters are the thing, yes, the nuclear power is going to get turned on. How early did you all switch to Active Storage? Too early? I'm curious to know more about that because I remember having pain with it. I don't know anyone who hasn't had pain with it, but it sounds like you've had unique pain with it.

Speaker 4: 17:06

Yeah, well, just because the way that Active Storage was originally built was totally makes sense for stream care, that product that I was telling you about, that's in the medical space. It totally makes sense because I want my assets to be totally secure, dealing with people that are accessing it or people that are loved in users and all that kind of stuff. But if you've got an RSS feed so we have hundreds of thousands of RSS feeds that all have images and MP3s and they're getting hit by ridiculous polling bots all the time Well, every one of those requests is going to your server and then get redirected to the actual source URL. Well, I remember when we were messing with it, we kept trying to roll it out. Every time we rolled it out it just crushed our server. We'd roll it back. We're like what's going on? What's going on?

Speaker 4: 17:48

And then we realized that every one of those requests it would hit our server. Then our server would check S3 to see if the asset exists. If it didn't exist, then it would create it and whatever. But even though all the assets were already there, that request, I want to say, took 600 milliseconds. It made no sense for some reason. The request to verify that the asset exists on S3 took so long that redirect took so long that it crushed our server, and so now we had to hard code it so that, rather than putting in the Rails slash storage URL, we actually linked directly to the asset, and that was the monkey patching that we had to do to be able to get it to work. And that's been in place really until most recently, with some of the public mode and some of the things that you can do with active storage. John Pollard on my team and Brian Treywick have been working really hard to remove as much monkey patching as we can to get closer and closer to the Rails.

Speaker 3: 18:39

But who among us has not monkey patched active storage at some point though?

Speaker 2: 18:44

That's all we do at.

Speaker 1: 18:44

Podia, yours was one of those things where they pulled it out of Basecamp and it was like they don't have any public files. So it was like they didn't even implement any of that stuff. But then it seems like a little bit of an overlook on the Rails core team to extract it and then assume that people aren't going to try to use it for public file storage. So it was one where it was like it felt like it was pretty half-baked when it got released, because you compare it to carrier, wave and shrine and all the other ones.

Speaker 4: 19:14

We went from paperclip yeah, we loved paperclip. Paperclip, paperclip.

Speaker 4: 19:17

Pretty exactly what we needed, yeah, but we were like no man, we're going to do the active storage, this is the Rails away and was definitely premature. And then they rolled out that proxy mode or something. They said, oh, active storage is going to work with CDNs and what it was doing is it literally will download from the CDN and then put it on your web server and serve it up from there. I'm like we've got petabytes of storage. I can't pull that down to the web server, but that was one of the early updates to active storage to be able to support CDNs. That's not what we need.

Speaker 2: 19:49

Did you know that the number one reason startups fail is that they run out of money? There are so many ways for startups to lose money, but downtime shouldn't be one. Recent studies found that downtime can cost $427 per minute for small businesses and up to $9,000 per minute for medium-sized businesses. That's every single minute, but a monthly subscription with Honey Badger helps you prevent costly downtime by giving you all the monitoring you need in one easy-to-use platform so you can quickly understand what's going on and how to fix it, which, my friend, helps you stay in business. And, best of all, honey Badger is free for small teams and setup takes us little is five minutes. Get started today at Honey Badgerio. Again, that's wwwhoneybadgerio.

Speaker 2: 20:45

I still don't know that. I fully understand the CDN support. We use it at Podia and I put it in Jobboardly the other day and I felt like the dog at the keyboard. I don't know what I'm doing. Like I have it working. I use DigitalOceanSpaces, which is like S3 compatible. But yeah, it was. I was just running to the problem where I had a job board with a ton of jobs and every one of them had logos and then it just crashed my server because it was making hundreds of requests to the server to talk to S3. So, yeah, that's a problem. Yeah.

Speaker 1: 21:15

We did a beginner Rails video and I finished the entire video and I was like I'm just going to show uploading file and then using ActionText. And then I was like, just on a whim, like we'll show the edit thing and show that it embeds that file there too. Turns out that DigitalOceanSpaces is very picky about certain thing for public access when you like resize the image or something. So I happened to just do this at the very end of the recording and it was like, yeah, that's broken. And I get looking into GitHub issues on Rails and it's well, we have to monkey patch active storage to include the public ACL or whatever on this specific request, just for spaces, not for S3. Because it Spaces is a S3 compatible, but not a perfect clone of the API or whatever. So you can easily run into tons of things like that. So luckily now a lot of this stuff is pretty solid. There are some gotchas and whatever, but it is Solid.

Speaker 2: 22:19

Solid, yeah, solid storage. I don't think it's solid.

Speaker 1: 22:21

Solid is going to help us with active storage. No Solid storage. Yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah.

Speaker 4: 22:25

Yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah.

Speaker 1: 22:30

Yeah, and yeah, yeah, yeah. So it's really simple. Yeah, I don't think that solid storage is going to help us with active storage. No Solid storage. We're just going to store everything on your web server. Yeah, yeah.

Speaker 2: 22:40

Just mount the 9 petabytes disk right to your server.

Speaker 4: 22:41

You're good to go, that would be the easiest painful to change, because you got to figure out how you're gonna get from where you are to where you want to be.

Speaker 4: 22:56

And so Cloudflare I have a mixed relationship with because I feel like they just own you and they're not as mature as Amazon like Amazon is very mature. I mean you don't actually know what you're gonna pay, but at least they've got a formula like you might not be able to figure out how that formula applies to you, but at least you don't feel like renegotiation all the time, whereas cloudflare they just call you and they're like hey, we want to talk and I'm like I don't want to talk to you because I know how this is Gonna go, and they're like well, you're using a lot of bandwidth, can we maybe talk about? And so I have to have this phone call with them on a regular basis. But to change is painful, it's just so difficult, and so, as a result, we tend to move pretty slow in changes in the area of the CDN and storage and things like that.

Speaker 1: 23:42

Makes sense. That's hard to pick up and move or make any adjustments to. It's not like redeploying your app to another IP address and you're off to the races. This is a ton of stuff, and the most important stuff in the product, so totally tons of caching that's out there.

Speaker 4: 24:02

You've got RSS feeds that are cached. You've got directories that have been built and they do not respond well to change. As a matter of fact, well, I told you that we're in the process of getting closer and closer to the rails on active storage and as we're moving in that direction, we made a change and we didn't realize inadvertently it changed the underlying URL. You know how. It kind of went up with a variant. It has a specific URL, based on what you do, to how you modify that variant and we didn't realize it. But in the process of upgrading to Rails edge and making some of those changes, it changed the variant URL. So when we deployed it, all of our RSS feeds, hundreds of thousands of RSS feeds, every URL changed the variant, which, okay, it's not that big of a deal when you pull down the RSS feed, except that those RSS feeds get pulled and when things change it triggers events on all these other companies, and so Amazon, their podcast hosting service. They reached out to us and what?

Speaker 4: 24:56

did you guys do Like our servers are blowing up and so it's impacting not just us, it's impacting our partners. And when we impact our partners, so Amazon. They delayed updating their RSS feed ingestion from bus sprout for 24 hours. As a result of that, we're like, oh my gosh, not a lot of people use Amazon podcast, but you might have one customer realizes it and says, hey, my latest episode isn't showing up in Amazon yet. So there's a lot of there's a lot of things.

Speaker 1: 25:25

Like you have the power over Amazon now because you can make a change, and then Amazon halts. They're like hold on. What did Tom do? No, what did Tom?

Speaker 4: 25:35

do. No, I feel like I can make their life miserable, but they don't care. I'm like you guys shouldn't be pulling us like that. You shouldn't be literally. I don't know how familiar you guys are with the podcasting and podcasting 2.0, but there's a much better way to do it. There's something called pod pings where anytime an RSS feed changes, people can subscribe, kind of like pub sub hub. You can use that too. But whenever the RSS feed changes, you can send out a notification, but nobody none of the big players use it. Amazon doesn't use it, Apple doesn't use it, Spotify doesn't use it, and so, as a result, they are literally hitting your RSS feed all the time, like every five minutes. And when Amazon first launched their service, I was like, look, you guys have an opportunity to do something way better than what your competitors are doing. And they're like yeah, we're just going to pull down the RSS every five minutes. It's so much easier. I'm like it's so much more expensive for everyone involved.

Speaker 1: 26:26

But that's the way they know, that's how they make their money. They're like well, we're going to get you to use more S3 bandwidth. And then that's funny. I was curious, going back a little bit to running all these different products, being in that situation myself, do you ever feel overwhelmed with like we got too much going on, and was that maybe why you know you led to shutting down some old stuff, that basically saying let's feature, freeze it and stuff?

Speaker 4: 26:56

I think in the office we talk about product guilt. That's what we call it. So when we're working on Buzzsprout, we have product guilt about tick, or we have product guilt about donor tools oh man, I'd love to be able to roll out this feature or do this thing and that's really the only pressure that we feel. And so we gave ourselves permission and we said look, we're not going to feel guilty, we're going to go all in on Buzzsprout. This is the product that we're going to be working on.

Speaker 4: 27:18

But you know, we've embraced a lot of the 37 signals culture and we want it to be calm, and that means that we're not going to squeeze every dollar out of our customers.

Speaker 4: 27:28

We're not going to feel this immense pressure to stay on a treadmill of rolling out features. We're going to do what's fun. I mean, that's literally when we talk about what features we say okay, what's its potential impact for our customers and delivering value? Is it fun? Is this going to be fun for us? And if it's not fun like it's going to get dinged, like we're going to put it down on the priority list and so whenever we go to the betting table to figure out which pitches we're going to take. Those are some of the things that we talk about, and so I think having multiple products doesn't have to be stressful and it doesn't have to be painful, but you have to give yourselves permission to not go after every dollar and to not feel the pressure associated with it, because you know, oh, you should be grinding, you should be bleb. That's just too much, it's not healthy.

Speaker 1: 28:09

Really like the terminology of product guilt. That's a really good. It's the exact feeling that I have on stuff that we've built and haven't really touched for a little while, and so like a perfect description of it and I guess just being like honest about, well, yeah, we're good with that. Like where it's at is fine, this isn't something we're excited about or whatever. Let's let it sit or whatever, and that's a okay. Do you combat that a little bit? Or does that get hard when people are asking for 100,000 new features and BuzzFraud or whatever? And how do you deal with future requests and like design, where we're going and make those decisions?

Speaker 4: 28:51

We want to be honest all the time, so suddenly talk about with our support team. We don't want to mislead people, and so we're honest with them If they ask for a feature. You and I were talking before we started recording about people wanting to edit the RSS feed we will never build that feature. We will never build it. So if they write in a support and they go, hey, I'd like to be able to edit my RSS feed, I don't want to write back and say, oh, thanks, we're going to add this to our feature list and we're going to share it with a team and blah, blah, blah. No, we won't do that, because BuzzFraud is built to be the simplest way for you to be able to host, monetize, promote your podcast, and this would make it really difficult and you could blow up your RSS feed and it's not a good idea. But here are two competitors that give you that ability. You might want to go check them out, like that's an honest way to respond to it. And so the same is true for all of our products.

Speaker 4: 29:39

For tick, somebody would write in and say tick is a time tracking application, but it's specifically for tracking your time to budgets. And so with all of our products. We want to be very specific. We say that we want to have a mantra, we want to have something that we do, that we can bounce all of our feature requests and ideas off of. So tick, for example, is the easiest way to track your time and hit your budgets. It's not the easiest way to track your time, but it's the easiest way to track your time if you're going to hit a budget. Perfect examples People would write in and say, hey, I want to do a weekly time card.

Speaker 4: 30:07

Well, a weekly time card. You will never hit your budget because you will wait until the end of the week or maybe the next week to actually enter in all of your hours for an entire week. You're going to blow your budget if you do that. So if somebody writes in with that feature request, rather than just giving them stock answer, we tell them no, tick, we want you to hit your budgets and because of that, we're not going to have a weekly time card feature, and so that's something that we try to do with all of our support requests and feature requests.

Speaker 1: 30:32

That's smart. You reminded me of a sales guy I worked with at a previous job. He was kind of teaching me sales and stuff and I think a lot of programmers grow up and imagine sales people and marketing is kind of like the car salesman just pushing products on Like you need to buy our stuff, like no matter what if it's good for you or not. You wanted time tracking use our product, nobody else's, and he was like no matter what.

Speaker 1: 31:00

Yeah, and he was telling me the same thing where it was like look, the goal here is get them to the solution. Hopefully it's your solution, but if it's not, tell them that and send them away and they will be much happier and chances are they will know a friend that needs time tracking and actually cares about the budget. And they're like, actually you need to go use tick and it kind of, in a way, ends up being sort of marketing where you've transferred Like this was going to be a failed sales for this person, just because of the nature of it. So let's just accept that and help them in general and then they will remember that it's a great experience with us, even though they didn't buy our product or whatever, and I thought that was super smart. It turns it into like, hey, we just care about you, we just want you to be successful and whatever, and if we're not the right thing, that's okay, which is amazing.

Speaker 4: 31:57

And, if you think about it, if you were to sell that customer, if you were to get them to sign up, even though they don't really share your this is where I was talking about how it's related to Rails If they don't share your opinion like we write opinionated software if they don't share your opinion, then you are going to be constantly battling them. They're going to constantly write in with feature requests that don't make sense because they don't share your opinion about how time tracking should be done, or they don't share your opinion about how podcast hosting should be done, and so you want to be as clear as you can with. This is our opinion about our product. If you share that opinion, awesome, we're going to have a great relationship. If you don't share that opinion, hey, you might want to go check out here Some other products that have different opinions. And it's not to say that our opinion is right or wrong. It's just that's our opinion of how we build our software and I think that's freeing, liberating for both you and for the person that's writing in.

Speaker 1: 32:45

Yeah, that is awesome. I highly respect that. I feel like, sadly, that's kind of a rare approach that people take. They're kind of worried about just making as much money as possible or whatever. And it's like reality is you probably make more money if you do the right thing and build the right reputation, because then people will come to you, because they know they'll be treated right or whatever. And it's a just short-sightedness or whatever. I think is they're like worried too much about making money today and not doing the right thing in the long run, which will end up making them more money.

Speaker 4: 33:21

So much programming has happened to people's brains to think that it's all about growth at any cost, why wouldn't you do something if it's going to make you more money Versus? Well, is it going to make you happy? You're going to be happier if you do that. And they look at you crazy, like why would you even ask that question? Well, because it's our motivation for almost everything that we do in life. So why wouldn't you ask that question about your business? Are you going to be happy if you build that feature, or are you going to hate your life because you're going to support this stupid thing that you rolled out because you had a customer that wanted it? Is it going to just suck the life out of you every day because you have to support what you were talking about Domain name management and stuff like that?

Speaker 4: 33:59

And I think that needs to be part of the equation and it's foreign to a lot of people. They're like well, you're leaving money on the table. Absolutely, I'm leaving money on the table. I'm doing that on purpose, because I'm optimizing my business for happiness, not just the happiness of the founders, but happiness of the team, of the people that are working on the product and our customers. I want to optimize for happiness for them. If they share our opinion, they should be happy and love the product, and that's, I think, just a different focus. And we have that opportunity too, because we're privately funded, like, I don't have outside voices forcing me. We've got a customer that wants this, you've got to do this. No, I don't have to do that.

Speaker 1: 34:36

Yeah, and that's something like Jason Fried and DHH have talked about to you. We don't have custom enterprise plans. Everybody is on the same public pricing, which means nobody has a larger say in the future of our business. If they wanted to take it away and demand a certain feature or something Like, we can say, ok, great, goodbye, and we lose $1,000 a month or something. But in the big scheme of things, like it doesn't matter. And the other thing too is like your business, if you don't have investors, your business is your life and you get to choose to do whatever you want.

Speaker 1: 35:13

And there was a period of time where I was kind of burnout and decided I'll do screencasts but just kind of play video games the rest of the week and I was kind of working four hours a week and so I hadn't even read the four hour work week book yet. But I was like, holy crap, that's good, that's kind of crazy where I'm just in a period in my life where I need to just take a sabbatical almost, but I need to keep doing publishing screencasts and stuff, and it was amazing. And then there's times where I'll have a kid last year. I'm going to take off, however much time, I need focus on him and whatever. And that is another sort of thing where you decide what you want to do. If you want to go be a slave to your customers and do whatever they ask for, go right ahead. You might make a few more dollars, but are you going to enjoy it? That's probably the more important thing, at least to some people not everybody, but they'll probably learn it in the long run.

Speaker 4: 36:11

That was maybe not the right choice or something, but I think it's like a dog chasing a car, like what happens when you catch it? When you finally get there, you're like I'm not happy and I love working with SaaS founders. And you talk to SaaS founders that build a product and sold it, and right after they sell it, there's this what am I going to do? Why did I do that? This is this thing I've been chasing for so long, but I don't know why I did that. Just like I was thinking of days in a car like why are you doing that, man?

Speaker 4: 36:40

It's not going to end well, if you succeed and I think a lot of SaaS founders they get into this mentality that has just been programmed somehow into our brains of just chasing every dollar and chasing an exit and no one is really chasing life, like what gives you life? What gives you happiness? Those are the things that you really want to be chasing, and then everything else should fall in line, and most of the time when you talk to people the times of your life when you were happiest, you probably weren't making the most money Probably there's no correlation between that. There's other things that go on in your life that give you happiness and joy in life, and those things are typically not related to money, but you wouldn't believe that if you go and you read articles about companies. Right yeah.

Speaker 1: 37:21

You have to remember that those articles are written to get eyeballs and whatever, so they're designed to get your attention and to sound like oh, here's the magic bullet, or whatever. But I think that's been half. The reason I've left Rails is it comes from that philosophy that 37 Signals puts out to you about building things in just a different way. And Jason's talked about just intentionally ignoring all the articles and all the stuff that's going on out there and just like figuring out what are your first principles, what do you care about, and then making decisions based on that and kind of intentionally being naive about what is the rest of the world doing, because then you can come up with your own answers that will actually make you happy instead. And your dog chasing your car thing reminded me of astronaut syndrome, which is you spend your entire life from a child to becoming an astronaut. You finally go to the moon or wherever, and then you come back home and it's like you're 30 something. What the hell do you do with the rest of your life?

Speaker 4: 38:23

Like what's going to do? You're just like yeah.

Speaker 1: 38:25

And you're just like well, okay, I hadn't thought about the long term at all. I was just so focused on making money or getting to the moon or whatever the short term goal was. And then you accomplish it and you're like it's done. I don't know what to do now and I'm not necessarily fulfilled for the rest of my life. So it's such a strange thing.

Speaker 1: 38:47

But if you look at it differently and you're like well, we're going to build a podcast product and then our goal is helping people share their stories and the higher level picture of it, and it's like we happen to make this product that needs to make money, needs to be sustainable and whatever. But our goal is not just to sell podcast hosting. Like that's kind of a shallow goal to have. Your goal is really way higher to help all these people like start their own careers or whatever it is. There's so much that podcasting really can benefit in so many different ways. And obviously that's what you guys are doing. And we're like so glad to have you in the Rails community and support you now, or now that we're on Buzzsprout. We're excited for that and it's awesome. So thanks for sponsoring the podcast booth, by the way.

Speaker 4: 39:37

No, that was like I said, that was just a perfect fit of we're talking about how can we get involved, how can we give back to the community and Amanda had the idea of being able to set up that booth and sponsor podcasters being able to go, and it was just, it was perfect.

Speaker 4: 39:54

And a drop in the bucket, a drop in the bucket compared to what we've gleaned from the community. Amanda and other people. Well, you just want to make sure you get everything out of the conference for your sponsor. I'm like you don't understand, like this is not about us getting anything. We've gotten so much. This is us trying to give back.

Speaker 3: 40:10

So I told we did a podcast with Amanda recently and I told her that it turned me into a diva. Now I'm like you want me to podcast at a conference without a booth and oh yeah, it's great to have nice equipment too.

Speaker 4: 40:22

That was fun. We go to a lot of podcasting conferences for Buzzsprout and everyone. There are podcasters and if they're going to a conference they're probably pretty serious, and so they're not as into the equipment as everyone at Rails world was. They're like oh my gosh, I've never used this microphone, I've never used this equipment before, and so that was a real fun dynamic for us as well.

Speaker 1: 40:41

Yeah, we're going to need a little podcast booth at each of our homes so we can record in that.

Speaker 4: 40:46

And roadcaster pros Everyone's going to have a little bit of a buster now. I didn't hear any sound effects on the the end.

Speaker 1: 40:52

Oh, Jason was pretty into it. On the second episode.

Speaker 3: 40:55

If I was able to reach across the table I would have been beaten on that thing like a DJ.

Speaker 2: 41:01

Yeah, I also figured out how to connect my phone to it, and so there are going to be a lot of copyright issues with the second one. Yeah, yeah, it's perfect, perfect. Well, tom, I'm really glad that you came and hung out with us today. Thanks for sharing, thanks for being part of the community. Really glad we have crossed paths in the last couple of years.

Speaker 4: 41:21

Thanks for having me and thanks for what you guys do for the Rails community. I mean, this is a great podcast and a great way for the community to stay connected and learn what's going on, and I've really enjoyed listening to it myself.

Speaker 1: 41:33

All of our rambling. Really it's great. Thank you, tom. That is the correct response.

Speaker 3: 41:38

you to Thank you, Tom, for saying that.

Speaker 1: 41:43

Thanks for everything and, you know, thanks for these stories of like, learned Rails and then changed my life and built a business and rubber. That was all the stuff. I couldn't get enough of those stories back in the day and that was like what I loved. And love sharing these things because I mean, it changed my life too. Rails has been quite a tremendous thing and when it's the one person framework, it is just such a cool place to be, a place that cares about. Yeah, we care about the code, but we also care about, like, more than the code and what you can accomplish with it, and that's sort of the thing I don't see in other communities and stuff. So it's just it's awesome to connect with people like you and your team is amazing and everything. So, yeah, thanks for joining us Been a blast. Thanks, guys.