Yo, yo, is remote Ruby? Jason, Chris and Andrew are here. Conversating, interviewing. You know, that's what they're doing. Let's put me in all Ruby up in here. Remote Ruby starts now. Hey, it's been a long time knowing Andrew this week though. He's out in the middle of the Grand Canyon as we speak. Is that right? Yeah, I'm going to look at his location. It hasn't updated in 24 hours. So normally, I'm glad he told us he's going hiking because normally I'd be concerned. But yeah, oh, man, he's
he's seen by a lodge. So I was going to say last scene at that Popeye's near his house. There's an Amtrak station near there as well. Amtrak being the trains in the US. I forget that that's the slow trains here in the US. We don't have fast trains. No, somebody like wrote a review of a new update train route from Chicago going north. That must be really interesting. They must be like a fresh take on trains and stuff. It was like, no, it's still the same old Amtrak trains. It's just that route.
Colin and I are talking about taking the train up from St. Louis to RubyConf in November. I think that'll be fun. Oh, cool. So you're going to take the train from New Orleans to St. Louis? We didn't discuss that, but that might not be a bad idea too. It's crazy how cheap it is. It's 25 bucks from here to Chicago. So that's crazy. That might also be around trip. I can't remember. The New Orleans route goes New Orleans. It's called the Spirit
of St. Louis. I think it goes New Orleans through Memphis to St. Louis. Okay. Yeah. That's not a reason I know about it because I want to take it to New Orleans, but it's longer than driving. Yeah. I know. I'm hoping that we get the correct one because there's one that goes from St. Louis to Chicago as mostly direct, but we didn't do that last time. And I swear
we stopped in every little small town along the way. And it took eight hours. It was longer, I think than driving because you had all those little stops. They're Washington, DC. St. Louis to DC to Chicago. Let me see. Let me look at this. This is important. This is what the people care about. Yeah, I know. Minutes of nothing. Glad to really bring the people what they want. I know. Oh, while I look this up, which I'll talk about last week, well, Andrew and I were out.
We recapped RailsConf with Kent and Colin. It was a good time and a lot of fun. I think Ufouca and Andy and the whole committee for RailsConf nailed it this year by far the best one I've been to in a long, long time. And they addressed every one of our complaints that we had discussed in the past and things we wish improved or whatever. The only single downside that we had noticed, and I was lucky this time, but the lunch buffets, they went
vegetarian heavy. So there was only one meat line and the line for that was insanely long and all the vegetarian ones were short. But there was three more vegetarian ones and one meat line. So it was kind of funny. But luckily, I was there like 20 minutes before lunch started. And then we're just like, I guess we'll just keep chatting and stand right next to the plates and wait for them to let's go. And sure enough, a minute later, they
were like, all right, you can go. We were like, cool. So unlike Railsworld, where I did not eat for two days, I eat good there. We got to stay in the GM evil layer building. It was pretty sweet. It had this one giant tower in the middle and then on the four corners for other towers or whatever, it looked like an evil layer of school. And then can't could wave across the river to Canada. So yeah, if you ever needed to like escape real
fast, just a little short swim away. I wanted to run a car while we were in Vermont and go to Montreal, go to the casino. But everyone with me, with the exception of Andrew, who would have gone, would have already like traveled into the US from outside of the US. And I was like, I feel like that might be risky taking you outside the US and then back in a SUV. Especially in the trunk. They do raise the question. Yeah, just hiding in the ass.
What was the vibe like when they announced that there's only one more Rails conk? They shared it to the previous year where they ended with kind of a rough note like that. This was actually really good because you could talk about it instead of ending the conference on a sad note like that. And then just everybody goes home depressed. It started out as, oh, that's sad. It started out depressed. Well, yes. But it was like, okay, we're definitely
going next year. And the conversation just felt a little sad immediately after a word. It was, ooh, I wonder where they're going to have it. I have to go to this very last one and whatever. So I felt like it created room for the conversation about Drew Bragg trying to convince desperately a darch that it needs to be in Philly. Oklahoma. In Philadelphia, Oklahoma sucks that it's the end of that. But it's also time to change
things up. Things have run for a long, long time and usually no matter what, there's got to be change at some point. And so it's time for that. So I think people are generally pretty supportive of that, which I thought was good. I think it's good. I think it stops the question of which one do I have to choose between to go to? Yeah. And the one thing we did think about as part of that discussion was there's only
a thousand tickets or whatever for Rails world. What do you do for all the people who couldn't get a ticket? And they no longer have a conference that's focused on Rails. But I said, go to RubyConf. I hope to see RubyConf be 600 people and it should grow as the alternative.
You can still talk about Rails at RubyConf. There's no reason not to. But there's also a lot more interesting focus around yet Rails happens to be a Ruby library, but also the Ruby LSP, the prism stuff, all this other things that make Rails as good as it is is discussed there as well. I'm hoping that RubyConf thrives some more. And I know they just are like, we're always organizing a conference even before RailsConf is over. We got to figure
out RubyConf and all of that is just never ending and stuff. So that's my hope. We get more BluDrid Ruby, Rocky Mountain Ruby, lots more of the smaller ones, Madison Ruby. And then they're not small either. They're 200 people for Madison Ruby. I think they're shooting for that or more, which is awesome. So they're not that small. That's 200 people I think was what RubyConf Australia was in Sydney in April. So I think what we'll hopefully see
is that we'll have more conferences of a decent size. And we'll convince you to do Southeast Ruby again and keep on lying out in Memphis. I really would love to do one in St. Louis sometime, but it's just so much work. I'm already way too busy and I would need all the support I could get, but I can't imagine this amount of work. I was sitting here a couple of days ago. Like we've had our oldest son breaking his arm. I can't sleep.
I had to go to the ER while I was in. Oh, really? Yeah. I had a bad reaction to some medicine that gave me to help me sleep. It's for a restless leg. It's not anything crazy, but I was so dizzy. The last night I retreated. Andrew and Harry had texted them. I was like, I need you to come to the hospital and help me. But between all of that, I sit in my
house thick in the other night because Blue Ridge is happening next week. And I was literally thinking, because Jeremy had floated the idea, what if we like alternated Blue Ridge, Southeast, something like that? It's actually really cool. The people involved with Blue Ridge were like, no, we don't want to like skip a year. Like we want to keep doing it. That's great. That's cool that they have that energy. But I was also sitting here thinking
if we had done that this year, my life would be even worse right now. It's just so much work to do that. Yeah, I can't really imagine trying to do that on top of everything else. Unless I had a team that was doing all of the work and I was just trying to rally people to come to St. Louis or something. Yeah. It seems amazing that they have that energy that they're going to do this year. It's awesome. We need more of that. I think it's
a matter of respect to everybody doing that because it is a ton of work. It's a ton of work. I also like Blue Ridge. I was looking at their lineup and there's just several like faces and people I just did not know and I just think that's so cool. Yeah. That's another thing those conferences are so good for is giving people opportunities to speak without having to necessarily like your first time be it rails world or RubyConf. I want to
go to Blue Ridge. I can't go this year. I'm in the same boat. Yeah. I was really hoping to and it's not that far away and it was another excuse to drive my car through the winding mountain roads and stuff. But yeah, between Australia, Detroit, Brighton, Ruby is about a month away trying to squeeze that in between and then knowing that I'll be going to RubyConf and rails world later this year. It was just I can't do another one.
But yeah, it's exciting because when I got into Ruby, I went to Midwest Ruby in Kansas City for a couple of years met some people that became really good friends just from being there for two days or whatever. Long lifetime friends from that and then we would drive around
whatever other I forget some of the names. So there was a free conference for a day that we drove down to once and just a whole bunch of the little ones through beyond ails and there may be a hundred people and those are just very fun time because it was lots of small groups and part of the real trouble with a conference of even rails conf size, which was I think 600 or so this year. You can't talk to everybody. I kept seeing Robby Russell
around but never had time to go stop and chat like I wanted to. Just same thing with tons of people and people who would catch me and hey, I wanted to say hi, but you were busy earlier and I was like, you just got to interrupt because that's what happens when the conference
is several hundred people or a couple thousand like it's been in the past and that becomes overwhelmingly big because you definitely cannot talk to everybody and I feel like I gravitate a lot more to spending time with my friends when it's 2000 people versus when it's smaller and it's 100 people. Oh, go talk to as many people as I can, especially the people I don't know.
That's a lot of to. Well, since you actually Jason started the conference by sorting people into groups on the screen and so here in group, it was one through 12 or something, maybe you got higher. There were no designated areas. You just had to go like find these people and so people like raising their hands like, you know, what number and like it was chaos, but it was cool because he did it twice and it forced you to talk to at least seven people
you didn't know. It was cool. That's really cool. I did for the first time and Colin's sent a couple times the scholars and guides program and cannot say enough good things about it. It's just welcoming somebody into a group of 600 strangers and trying to make sure they have a great time. And that is from experience going to conferences and not knowing anyone
at all, it's awkward conversations the whole time. And then the next conference, you're like, oh, hey, I remember chatting with you last time or whatever and it starts to become easier and easier, but you might be afraid of going up and saying hi to tender love or speaker or something. But when you're like there with a guide who already knows a bunch of people, one of my favorite times is going to RailsConf with you. I forget when it was
but everybody knew you and I was just tagging along behind you pretty much. And I was like, this is wild. And I got to meet a bunch of people. I forget when that was, but I remember very fondly, everybody knows Jason. This is crazy. And no one knows who I am. But then I got to meet everybody through you or whatever. That I think is something every conference should do. Welcome people. You could volunteer for it or whatever. You don't have to give
away free tickets and all that that RailsConf does. Ruby Central, I should say because they do that also for RubyConf. Just that whole thing of partnering people up who are strangers and making sure everybody has a good time and doesn't feel out of place or awkward or whatever. It's great. Yeah. Phenomenal. Yeah, I agree. You mentioned Robbie Russell. Have you done the Rails survey? Yeah. No, I keep forgetting about it, but I need to. It goes
until August. Oh, it's open for a long time. Yeah, it's open all summer. I think it was on that one. Robbie actually reached out. And so I'm going to use this moment to share a few words about the survey. Yeah. Here's what I'm going to say. Hey, Rails developers, it's that time again. And it argons. I don't know that word by an eel. By annual. It's
B-I-E-N-N-I-A-L. All right. We're going to drop it. I thought it was by an annual. I'm not going to show myself like this, but then it becomes one of those terms like by monthly is every other month or twice a month. Twice a month. God knows. God knows. All right. It goes something along the lines of hey, Rails developers. It's that time again. Planet argons every two year survey. Oh, no, that doesn't work. Don't they do it every year? They
do it every other year. Really? It's not every year. Yeah. Oh, something along the lines of hey, Rails developers. It's that time again. Planet argons survey of the Ruby on Rails developer community is now open. They've been surveying the community since 2009 and publish all the results for us to learn more about our tooling versioning, educational resources, and so much more. You can browse past results and participate this year by visiting
RailsDeveloper.com forward slash survey. And I promise that wasn't a pre-written message that Robbie shared with me. You're just so articulate. That is what you are. That's what we work on here in Memphis, being the best at talking. Sounds like it. Everybody should take that survey. It's very important to kind of get people a pull sign Rails and what's changing and what's new and what's going on and all that good stuff. So it's important.
It's much more accurate than this sort of, oh, well, Stack Overflow doesn't have a lot of Rails postings, which means that Rails is definitely dead. That stuff is never accurate or anything. So these are the ones to look at or whatever or so. Yep. How has- I'm going to do it. I know because it's pretty long survey. I'm looking at the size of the scroll bar and I'm like, this is going to take a minute. You guys have been out
and your company retreats. How's product stuff been? I think you guys have released some new stuff at Podia recently, haven't you? If I remember right? Really is the blogging feature and then- I saw the blog. You guys watched that. There's a guy, I think his name was David Heinemeyer Hansen, a while back posted a video about a blog. I've seen software. We were inspired by that. It only took us 15 minutes. We shut that feature. It's pretty
nice. Oh, and- I just feel a lot of stuff. Andrew just released. We have a disc board integration now. So when people buy products, you can- Oh, I saw that. I rolled them. Yeah, Andrew worked on that. Andrew and David- That's cool. I've been in a code factory with- Oh, Java Land. Yeah, see, see, see, we've been building factories and builders. I'm going to say something that's going to contradict all other 200 and
whatever episodes. We need a belief button just for the fun of it. We do need that. SDI didn't scale very well in one part of our code base and I'm scared to say that out loud. I think that seems like a common kind of- Don't you dare slander SDI? I like it, but it makes sense too though. Someone said from GitLab that they had notifications using
SDI for the different types and that table just becomes a freaking massive table. And so at some point they break it out into their own separate tables for different types and notifications, which makes sense. But it's also the size, the scale problems that- Yeah, you're going to have to build unique stuff at a certain scale. No matter what you do
at a small scale, it all generally works pretty fine. But you'll run into those bottlenecks, which part of building software I think doesn't make SDI bad. Yeah, it's worked for some years, but we have some things on the roadmap. We want to do that require us. They don't require, but if we want to do them well, we need to kind of unangle this a bit. So we're switching some stuff over to delegated types. Yeah.
Which I know, that's what I was going to ask you is if you move it to delegated types, it's effectively the same conceptual thing, but it's Holly Morphe join table. You're just kind of moving it up a level of abstraction almost or moving it out, tracking it. That's exactly what we're doing. So basically, I guess we can talk about this. We have this model that represents a course, and then every product type we've added since then has inherited
from that as like SDI. But that means course is the source of truth. Course isn't the only thing we sell it, Podia anymore. And so it's a bad representation. And a minimum the naming is incorrect. And most it doesn't represent that. And so like when you buy a webinar, you're not buying a course, you're buying access to an event, stuff like that. And so we're untangling some of that.
And the abstraction really here is like everything is a product, right? And so, but before that, digital downloads and our system used to be called products. For the past five years, I've been naming things product, knowing that we're moving to like this one day. But I had to go undo all of that for five years because we needed to clear up the word product to make it clear what a product is. And we're running the side by side right now.
And so yeah, it's been wild, but it's worth it. It's just a lot of work. Yeah, you're rebuilding the plane mid flight. Yeah, that's definitely tough because it's one of those technical debt things you knew about five years ago. And it's hard to keep the pace of new development and features and growth of the business. And then we'll kick the scan down the road a bit. But we'll try our best to keep it in mind as we're working. And then at some point,
it comes to we need to do the hard stuff now and clean it up in a similar vein. That's what Collins been on with cleaning up my old, I never really planned gorales to be sold to teams. So I saw that announcement. Then I saw you think calling that thought, yeah, that all checks out. Yeah, quick question for you. Do you want higher clarity into production, but don't have the time to become a wizard in observability. Honeybedger insights is exactly what you need.
Forget the old school trio of logs, metrics and traces. We're talking structured events, but don't just sit there. They're your treasure map to solving mysteries in your app. With honeybedger, sling your logs and events into the mix and voila, you just unlocked the power of honeybedger's new query language, badger QL. It's like having a conversation with your data. Ask it anything. Turn mishaps into metrics and showcase your wins on dashboards that even the
marketing team will drill over. And guess what? This isn't just for big spenders. Honeybedger's got you covered with a free plan that packs a punch, including air tracking, uptime monitoring, sleek status pages and more. Oh, and speaking of errors, honeybedger treats them like VIPs at the club. With insights and badger QL, your errors aren't just problems, their opportunities. Explore your data in ways you didn't think were possible and
get the insights that you deserve. Check out honeybedger.io. That's right. honeybedger.io. In the very beginning of Go Rails, we start adding teams because somebody requests it. I don't really want to go build a bunch of stuff for teams that may not ever be used, but I could hack together a user belongs to another user. And we check the current user's subscription. Or if they happen to belong to another user, check that person for a subscription.
Simple as that. And we just assign literally just one new column and then one extra check to see if you're subscribed or not, not a big deal at all. So that survives for over 10 years, or whatever, which is great. But we were at the point where we're like, the teams plans are sold in blocks of fives. So you have a team of three or a team of eights and whatever, you're either overpaying or underpaying and you can't get exactly what you need on your team or whatever.
So we've been talking about, let's just go make that change and make it using Stripes quantity option for the line items. So we'll just put you pay for five or 10 or eight or seven or three or whatever the number is. And it just multiplies it. You then have those seats to assign. And we already kind of had the assignment of seats because the plans would keep track of how many users were allowed. So then we're just looking at a different place for the quantity now instead of the thing
in our database for the users allowed. And that worked out pretty well. And then we were like, you should ideally be able to remove somebody uncheck them and then automatically update the quantity and the pricing because they don't have pro access anymore. That sounds simple, but then if it gets changed and striped, then we got to make sure that's updated and then there's other situations where you're checking out and you pay for eight, but then you're the only person on the team so far and
you need to invite the other people. So a web hook might come in, you paid for eight, web hook from Stripe comes in, we recalculate and see that you only have one person. So then we'd drop it back down to one and the complexity of that is where he was able to like get a good chunk of that in there. And then we start reviewing the code at some point. And I'm thinking about edge cases and I'm like, ideally, this seems like a good plan. But we can tell that it's becoming harder
and harder to think of all the edge cases. And so we ended up just screw that. We'll just make it easy for you to just and click save and update the quantity on your subscription, change it to exactly what you want. And it's manual. It's basically the same amount of work as a user. But you know exactly
what you're going to get all the time. And our code can be 100 times simpler. But I was definitely one of those, yeah, here's a bunch of technical debt built up that we need to clean up because we had also built a little one off prices for different people that we had done in the past because we didn't really have a promo code thing because that wasn't really part of the card element and stripe. And also we had used brain tree for PayPal and we pretty much hidden all the PayPal stuff.
We're not accepting new PayPal customers. You can pay through any of the crazy amount of payment methods on stripe. So that didn't support promo code. So we'd have to build something custom and then do all that with the two APIs. And we didn't want to do that. So now we've got the promo codes and we can just use that. And it's way easier. Like we had thing with women who code. So we gave
them a discount, which sadly they shut down, which is all that real sad. But if anybody comes to us and needs a parody discount or whatever through because they live in Brazil or whatever, hit us up over email. We'll give you promo code and it's way simpler now instead of we link you to a special plan and whatever. So now we can condense all of our plans into just one thing and do the quantity based stuff and life is much simpler. But it's not as fun. Yeah. And it was funny too because we're
in the middle of it and we're like debating some of these options. And if we couldn't migrate those team plans over to quantities, then it was going to be like, well crap, we have to maintain both now, which is we have a better cleaner version. But the same problem is writing rails or libraries. You were stuck with the legacy code until the next major release where you can after it's been deprecated, you can actually finally remove it. In products, you're hoping to be able to remove
that craft immediately. No, if we're going to get in a situation where we're going to have to keep around the old craft and the new stuff, we need to evaluate. Yeah. Because then this isn't going to help at all. So luckily we got through that. But it was one of those moments where you like, you know, as a developer writing the product, last thing we want is to have to keep around the legacy stuff, which I think is probably why you see a lot of companies cutting their old grandfathered
things at a certain point. They try to keep it as long as they can, but at that craft, they're trying to get rid of internally, which always sucks because it's usually comes with the, now sorry, we're getting rid of that plan and we got to raise prices on you and whatever else. User voice was what I used to use because they had a free customer support plan or something 10 years ago.
They just emailed me. They're no longer going to offer the free plan. It will be $39 a month if I put my card in and that is a 96% discount of their current pricing of whatever now is like I need to go find their pricing page because what the hell is going on here? So we haven't used them for a long time, but we're still, I guess, getting the emails about it. But 39 a month, that sucks. We were used to a free plan because we didn't use it much or whatever,
but I understand sort of the need to maybe get rid of that at a certain point. And then this is a 96% discount, caught me off guard and I was, what the heck are they charging for this now? Excuse me. Yeah. So it's like a thousand bucks a month now that they're, I guess, going B2B upmarket or whatever and focusing on that. But I'm good for the thing, dude. Yeah. So that was quite the
surprise to read. Oh, okay. Real quick. Where I showed this other thought. With the STI to delegate type conversation with the conversation you just had about moving your subscription stuff around. I can't speak for you, but I still feel like in both of our situations, it was the right call back then because you don't know if it's going to scale, right? You don't know. Yeah. I don't regret it at all. I guess even then, podium wasn't always podium. podium was coach before that was not
so ill say that software. It was for LSAT tutors. And yeah. So I guess that's the interesting thing. Like hindsight's 2020, if Delhi, if telekated types would have existed then and B, if we would have come out of the gate with that, we'd have gotten it wrong. I always point this out to people too that delegated types did exist then, but you just had to set up your own model with the polymorphic association. Yeah. Basically, no one actually really recognized you could do that or thought about
it because it wasn't a common pattern. It's so helpful now that it has name so you can actually talk about it and discuss it and everybody's kind of on the same page with it now. But you could have done that before, but you probably wouldn't have thought about that. It's not a silver bullet. There's been a couple of times where I'm like, is this better than STI? I don't have a specific
examples right now because I've been off that project for two weeks. But so for anybody that's not really familiar, like STI on a basic level is everything's in the same table, a product's table, maybe not the best example. I always like looking at base camp and you have project with events that happen and everything would have to be like the same database table for the basic storage of things. And then when you pull one of those records out, it can tell that it's a
message board post or to do item or something. But you would weirdly have to shove them all in the same table in order to do that. And then delegated types is like, what if we have an events table for a project and it references a bunch of other tables. So you actually have a separate message board table with all of those posts in it. And events just connects that between the project and
the message board. So you have sort of the separation between those. So you can actually organize things and separate them out because technically a for Podia, for example, a course is very different than a digital download and a webinar and a blog or whatever that you've got in there. Those are all very different types. Need to store very different data. And STI is really designed for they're all the same thing at a base level and like have smaller variation between them.
We use STI for our page sections on our sites. That makes sense because the sections are all roughly similar. It makes sense until it doesn't. Pretty much for me, it feels like a smell when I need to add a column. Well, this column fly to everything. And if not, okay, to be fair to, we kind of we get around that a lot because we use JSON V. Right. Right. Call them. Some things will have some text content that others won't. And it works really
well for that. But I'm not going to do any type. I don't think I'm going to get to see any type of relationship in JSON B because that's not what it's designed for. Right. That one's a good example where it's right at the very edge of maybe not a good fit for STI because if you start, this section has text. This section has an embedded video and the video is in a library that can be reused multiple places. You end up starting to break up the data for each of those is quite
independent at a certain point. But using the JSON stuff helps you keep them similar. That's why for notice STI makes a lot of sense because in notification generally has one record. It's related to that spawn like a common spawned notification. And then we might provide extra context in there of what the action was the comment or the pull request was reviewed or whatever the action might be and all that makes sense to just shove in a JSON B thing. You're typically not going to be
querying on it. But also when the comment or pull request is deleted, we can use a regular, it has many notifications to dependent destroy without going through in the past. We had done that through the JSON B which meant you had to build your own custom destroy call back in order to make sure the notifications were queried against the JSON B data to find here's the notifications that reference this object. So that when you start recreating things that are in active record
then you're definitely pushing the boundaries on it. It does work out pretty well. But I could see a future version of notice having maybe delegated types and STI or something where it's you're creating the notification records themselves which is the main thing but then they could point to like another table for extra data or something and that could even be STI itself or whatever.
There's probably some cool crazy ways of implementing it but I think that's a good way that you're pointing out sort of it's a blurry boundary of where STI is not the right call but it can be very hard to notice that until it's too late or something. It's too late. Again, made the right call when we did it still stand by. Yeah, it's interesting. So I talked to somebody this morning similar conversation.
Basically, he's got an app that has integrations to these services. He's building the very first version of the app and it's got five different types of integrations. So similar to like catch box we have integrations to hosting providers for creating servers for creating managed
databases and then get providers and those are three separate types of integrations. So the way that the code is being written currently, he was a little concerned with because each integration is directly implemented as opposed to building an abstraction layer over that which is here's the actions we need in order to for example with catch box to create a server on digital ocean. I can just create the server but on AWS I might need to create a VPC and submit and choose that
before I can create the server. So we can just have the set of every service that we do for hosting can have the create VPC step and then the create server and maybe some of those haven't just an empty step for creating the VPC because we'll use the default or they don't have VPCs. So we effectively have a null operation there and just skip that step for those and I was telling him you probably want to do this because it's the same issue of coming back and adding team support
later on. We're doing anything where you program it for one thing but in the future it might be a
loop of things and multiple things you have to deal with. If you have to go and change all of your code that goes through and assumes there's only one to now there's potentially six or any number you have to change it from a current user dot project to current user dot projects.find and we have to have a D and it becomes a nightmare to kind of think about it that way later on and refactor that and I was telling him you should probably have them go back build the abstraction for these
types of services. We need these general operations the details of how they actually need to work with Hetzner versus Digital Ocean versus AWS. We don't care at this level we just want to say hey create a VPC create a server delete a server and we wanted to like plan for that today so that it may not be perfect what we envision right now but we'll figure it out as we get into the details but at least
we can have some foresight into where are we headed so that we don't code ourselves into a corner and then have a really hard time refactoring I've been there done that and then I've written things in jumpstart that are thinking about that ahead of time and then you're like holy crap yeah
there are those moments where you like we still didn't envision all the issues that we would run into it just got worse times where you're like I can't believe how easy this was this took five minutes and I thought it was going to take two months so those are the hopeful goals you can plan
for or whatever but you don't necessarily know there may be some weird things but I feel like putting some thought into it ahead of time can really save your butt in the long term right in the butt if anybody saw that wheel of fortune thing oh my god the problem for me is I go the other direction
where I try and like solve it ahead of time and then never pants out I never encounter the problem and so it's a balance it is yeah because in this case he knows he's going to have many of these but they only wanted to code it for the one at the beginning when you know ahead of time you should
definitely do that this is also the hard part of building jumpstart is the same thing is building libraries and knowing that okay I'm trying to write an admin interface they could be used in any situation for any application for any database for any thing and it's impossible to build because
you cannot even remotely imagine the use cases that you will have those become really worthless things to try to solve because you got to set some constraints so you can even start it's definitely a balance trying to figure that stuff out before we wrap you're talking about subscriptions to see
the other thing we changed job poorly to one time payment it's a bit of an experiment but the experience going quite well we'll see how it pans out long term but holy shit I still have to support subscriptions because we didn't yeah we didn't move people on subscriptions off but
the code is when subscriptions if and when they're gone holy shit I forgot how much wanted is to write applications that don't have any type of recurring subscriptions yeah that's super cool dude the 247 forever you inspired by once on this one at all we talked about a little
bit we ran a couple of lifetime deals before we launched kind of targeted and we had a pretty good success with minimal effort pretty qualified the people reach out to you but yeah so we'll see how it pans out keep doing the math I think it works it's weird it doesn't preclude you from
the one power user who's yeah I got a hundred thousand jobs and I need some extra features and whatever and I paid 249 this that person or whoever the crazy power users are we'll be willing to like it can we hire you do a subscription so that we can just have you on hand keep this up and
running for us or whatever else right I think in the long term we will probably see a lot of businesses doing one time payments subscriptions for the people who make sense to have them and then also like a consulting wing you can imagine a hatch box in a similar vein of you could pay a hundred
bucks or whatever it is for maybe one server lifetime maybe we just do that and it's your side project server whatever we'll just make it easy for you it'll be cool right you're not going to be deploying a ton of that if it goes down it's not that big of a deal or whatever because it's
side projects and whatever but then the people who are like we have production stuff and we want to make sure that we are going to be able to upgrade to the new Ubuntu LTS version and run the latest Ruby right away and all that stuff they are a bit more demanding they need the constant updates
and whatever else because they are staying up to date and then there are also the power users who are like hey can you help us optimize our app for this configuration whatever else there are those customers who would happily pay you ten thousand a month to have your expertise and
really optimize that and I feel like there's probably going to be that as sort of a great complicated I guess having the three different sort of business models but in theory you can be profitable as a company very quickly rather than we only sell subscriptions and it's going to take us
five or ten years to be ramen profitable or something because you just don't have people are afraid of commitments on subscription and if it's a first side projects I don't really care if I just charge you a hundred bucks and then you don't have to worry about it I don't have to worry
about it we agree that that's the relationship that it is low priority relationship can't shake agreement yeah yeah that's the thing that kind of changed my mind on it it was Kyle's idea you were in cost every month yeah yeah and then I like did the math a few times and then what I
thought about those when I started working on job worthy with you like my whole thought was there's a lot of job-wards software but they're mostly targeted toward power users and like where it's like the software for people who like want to get started with a problem two people want to
get started it takes a while to get it going if they don't see something two three months in or they're not it's like aunt about anymore they'll turn out and so hopefully with this it's a little bit more upfront commitment but you can write it out longer like once you've done it in theory like
right could be done and then if it takes you a year six months whatever two years you'd be more successful it's kind of the difference on you buy a course versus you subscribe to go rails it's a bit more commitment that you're signing up for mentally you pay for the course one time
you may never go through the course but it's there if you want to or whatever it's on you yeah the subscription feels like a continuous sort of nagging of hey are you using this right it's got its pros and cons as well because it's cheaper in the moment or whatever and if you're
subscribing for three months it's way cheaper than buying a course for two fifty or whatever so right or it's great for the business owner to have the people who are like we're just committed to support you forever and that helps make it less scary as the business owner because it's well we
can rely on having a salary I know that I will be able to pay Kent and Colin to continue doing support and making content and solving my own old technical debt I think it's going to be interesting to see that as more entrepreneurs are probably going to end up with three business models because
at the end of the day you have some customers that would probably happily pay you a whole crap load of money and other customers who just I'm dabbling and I can't afford a lot if you only have one price you cannot accommodate those two types of people and that may be a good thing
you hear Jason and David talk about that with base camp no one can pay us more than whatever $2.99 a month or whatever it is so we can't have Amazon come in and be like we're going to give you a million bucks a month and we're going to use base camp and then they start leveraging their
thing and like well we might cancel right if you don't build these features then they're not on the hook as a business that is maker break dependent on this one customer and these are things you figure out over time too you can adjust and see but in the beginning try it experiment we did
jumpstart as a one time purchase for a long time and then we realized so many people want us to keep it up to date the only thing that really makes sense is for us to have a subscription so if we're not updating to rail 72 and rails 8 and whatever people are going to be mad so we now have it
as a subscription which makes sense and sustains it and at the same time we offer effectively the one time purchase because you can buy it and cancel and not re-subscribe next year and you just won't get the updates past your first year of ownership cool maintain it yourself at that point
and you only have to pay that you don't have to re-subscribe it's kind of the way to do that two business models almost yeah that's exciting man I'm curious to hear out ghosts lyricals has always offered they'll four hundred dollars lifetime subscription price and I
thought that was cool so maybe that'll be an experiment for us go rails one time I know we kind of talked about it last year and just didn't have time to do it before black Friday but we thought we might try it see what it's like but yeah see if it moves the needle yeah yeah we'll see
that's good we did it yeah effectively beginning of the month do you have a window that you were going to experiment with this for or just plan to just roll with it until you decide it's working or it's not working well yeah that one it's been really good for us so far and so
we'll see how next couple months do but yeah all sounds look good right now and it's a risk right yeah but it wouldn't be fun if it wasn't right that's kind of the thing you don't know what will happen so worst thing you can go back to what you were doing before best thing it might end up
selling like hotcakes you just don't know and it's sort of the worst case scenarios we just go back to where we were at you're not taking life or death risk with it right I think worst case scenario I'll live in my parents basement if go rails doesn't work out or I'll just get a job
I wasn't risking anything that crazy at the time because it was just me and my cat it didn't really matter that much I was a good time to take the risk and gamble so I think you're in that position and it's a good thing to do and I'm really curious to follow up on this in a few
months time or weeks time or whatever maybe tomorrow you'll see yo this is working have you considered launching it on product time again and sort of launching it to do some more marketing of hey we're one time purchase now it coincided we recently did a product launch and that
oh nice coincided with it yeah so maybe I did see that now I'm remembering that it wasn't I think I'll do it you did I appreciate it it wasn't like an explicit like hey we've launched as one time payments the first time we even done a product launch so it just oh okay that's right
yeah I thought maybe you had before but that makes sense that's a good way to test it out and see if just strangers that's the thing about product time it's just random people that are interested in products they're not job board creators or owners or anything right so it's a very kind of
useless audience but also it's a good one because they're entrepreneurs so maybe they are like a design job board because I'm a designer makes a lot of sense it's into my yeah so it's maybe not the most targeted audience you can have but it is a good one same for like to launch jump starter
go rails on there they're entrepreneurs maybe they want to build a product in rails or ruby or whatever and it kind of fits but we wouldn't expect a very large percentage of people to convert or whatever the fun of trying to do marketing so what I have Kyle all right well exciting well
do it again next week yeah everybody go do the rails survey and make sure you submit that giant form trying to make it so exciting I'm just looking at how many things I've got to answer but we're going out for a birthday dinner tonight so I've got to make sure get it done before then
okay it's the 25th right yeah I turn old 35 I move from one of the brackets 25 to 34 to the 35 to 44 or whatever yeah so I'm moving up age brackets tomorrow which is interesting but we've got the pool open it was very murky this it's still fried so we're still waiting on them to get a new
salt cell installed I guess but I'm looking forward to summer but with all the screaming cicadas out here it's just kind of a baseline level of insanity so we'll see how the pool actually ends up if it's relaxing at all I haven't questioned it all right man enjoy chat yeah see you