[00:00:05.19] - Robby
Welcome to On Rails, the podcast where we dig into the technical decisions behind building and maintaining production Ruby on Rails apps. And I'm your host, Robby Russell. I run Planet Argon, and for over 21 years, we've helped teams maintain and evolve their long-lived Rails apps. So I tend to approach these conversations through that lens. In this episode, I'm joined by Bryce Harlan, a senior principal engineer from Jaan Health. Bryce has spent the last decade helping evolve Jaan Health's Ruby on Rails platform, which supports healthcare providers and care managers as they coordinate patient care between office visits. Along the way, the team has navigated major Rails upgrades, large-scale Sidekiq workloads, and the realities of maintaining a long-lived Rails app in healthcare. Bryce joins us from New York in the United States. All right, check for your belongings, all aboard. Bryce Harlan, welcome to On Rails.

[00:00:53.22] - Bryce
Hi, thanks for having me.

[00:00:55.14] - Robby
So Bryce, To kick things off, what keeps you on Rails?

[00:01:01.03] - Bryce
Yeah, it's a good question.

[00:01:04.01] - Robby
Thank you.

[00:01:04.23] - Bryce
I think for us, Rails is sort of the sweet spot of the ecosystem is really lively and effective. We've been on it for 10 years, so there's a little bit of inertia there. The things that drew us to Rails in the first place, so things around making products quickly, iterating quickly, spending a lot less time in the weeds of what makes a web app a web app are still things that keep us staying on Rails.

[00:01:39.23] - Robby
So I always find it interesting, and in our previous conversation, for our listeners, we have a pre-interview conversation, maybe a month or two ago, and one of the things that stood out about you was that, You didn't work with Rails prior to this job, right?

[00:01:54.22] - Bryce
No.

[00:01:55.16] - Robby
So how long have you been with Jaan Health at this point? And can you tell us a little bit about your background there prior to coming to, like, what tech stacks were you working with?

[00:02:03.23] - Bryce
Yeah, so I joined the company about 10 years ago, actually almost like 10 years to the day. And so before that, I worked at a few companies where the main web app components were all written in Flask. There was one that had There's some services in Node.js, but yeah, hadn't touched Ruby, hadn't touched Rails  at all. And my background at the time was really more on, like, the math side of things. So, I was kind of a very classic, you know, math programmer where all the variables are, like, single letters and things like that. So, yeah, I think that having, coming to this company, getting used to Rails , it was especially enlightening, 'cause there was a lot of things that felt A little bit obtuse is a good word for it, I think, but, you know, like, just dealing with middleware and dealing with all these layers that, you know, as a math person, I'm like, I just wanted to, you know, to talk about what matters. And then Rails  came, and I was like, oh, I can actually focus on the thing that I'm being tasked with building, not all these other details.

[00:03:13.10] - Robby
You know, when you think about working with, I think it was Node.js and Django and Flask that you worked with prior. What felt familiar when you started working with Ruby and Ruby on Rails , and what do you think felt completely foreign to you?

[00:03:27.01] - Bryce
I think the things that felt familiar were just the overall architecture. So, the MVC pattern, that landed pretty quickly with me. I kind of was easily able to map. I was like, okay, yeah, this is this thing, this is that thing. Some of the things that felt maybe less familiar, I mean, one, just Ruby, it was a very different-looking language, like, on a sort of a superficial layer, but I was like, "Where are all the parentheses? What's up with, you know, these block statements?" and things like that. But that was a pretty welcome change. Yeah, man, I'd have to really dig back into, some of the other things, but, oh, you know, a really good one is ActiveRecord. I think the ORM is just something, especially, you know, back in sort of 2014, 2015, getting to use something like ActiveRecord just felt like a complete change of pace, you know? I was used to writing SQL and writing lots of it, and going to making that feel a lot more like code was very different.

[00:04:35.01] - Robby
What stood out? Compare with other ORMs you might have interfaced with before? Or were you primarily just working in scenarios where it was just a lot of raw SQL, or were there—

[00:04:44.12] - Bryce
So, I mean, I guess to pull from a slightly more recent example, I recently helped our AI team spin up a web server around some of their Python code, and that was written using FastAPI and SQLAlchemy. So SQLAlchemy was the ORM layer. There. And I think the amount of indirection that you put in between, and that it's really your job as a developer to manage that indirection. So, having these dedicated service layers, you end up almost rewriting what feels like, in Rails , big parts of ActiveRecord, just in your codebase, just to do basic stuff like listing, sorting, ordering. Chaining scopes, things like that.

[00:05:32.03] - Robby
How has your, maybe your appreciation for ActiveRecord changed over time then?

[00:05:38.13] - Bryce
I think it's only grown. I think it's one of the things that we probably use or try to take advantage of the most in our app, especially for doing, you know, some of the stuff around creating views with pretty complicated filters and things like that, being able to treat those just atomic scopes and chaining those together is something that the more I use it, the more I'm rewarded by using it. And yeah, going into other places like that SQL model layer, it just felt like I was like, oh, I'm missing a critical tool in my tool belt.

[00:06:14.06] - Robby
Right, right. So before we get too much further, to help our listeners better understand the world that you're working in, in particular, maybe set the stage for everybody listening, Can you give the listeners a high-level overview of what Jaan Health does?

[00:06:28.07] - Bryce
We are a web app that helps clinical practices. So think doctors, nurses, they buy our tool and we help them with managing between-visit care. So it's a lot of healthcare that happens outside of the 4 days a year where you go to a doctor or the 1 day a year or the no days a year for a lot of patients. Helping with things like medication, symptom reports, stuff like that.

[00:06:57.01] - Robby
So who are the kind of primary users of the application? Is it the practitioners themselves, the care managers? I'm not sure the terminology you might be using for that.

[00:07:06.05] - Bryce
Yeah. It's mainly sort of nurses and care managers. Practitioners, physicians, they'll use the platform in more of like an overseeing capacity. And in certain cases, you know, smaller, smaller clients, they might have a more active role, but I would say nurses and care managers are the primary users.

[00:07:25.11] - Robby
So what are, what are these users actually doing inside the application?

[00:07:30.00] - Bryce
Yeah, it's a great question. So they're putting patients on clinical protocols. So they will go based on who you are, you'll get your own custom pathway. And that person is They're kind of acting like a quarterback almost. Like, so as you, you know, we work with a lot of older patients, you know, and so older patients, they see lots of different doctors and they have lots of different medications and there's a lot of coordination that needs to happen. And so having one central point of, you know, hey, I'm trying to get something approved by my insurance, or I'm, I'm not sure where to look for the results of my latest blood draw or something like that, there, there's someone that can receive those questions and then also doing a bunch of proactive outreach. A lot of times people are fairly, you know, they want to be independent, they don't think they need help. Healthcare system usually isn't super friendly to, you know, it's not the most welcoming space. So they're like, oh, I don't— if I end up trying to get help, I won't get it anyway, so why even bother? And so reaching out, creating that relationship and helping.

[00:08:37.18] - Bryce
And so Yeah, in terms of what they do on the application, it's a lot of just sending messages back and forth with the patients, reviewing things like those plans, making updates, sharing documentation back to systems of record.

[00:08:51.15] - Robby
So is this a safe assumption there's a lot of HIPAA compliance involved in this?

[00:08:55.23] - Bryce
Oh yeah, everything is fairly sacred. So yeah, the whole app needs to be fairly locked down.

[00:09:05.01] - Robby
And we've talked to a number of different people on the podcast so far, different guests that have worked in companies like Doximity and I think even, well, Gusto, I think has more like PII information in their particular, but that does have healthcare related. I don't know. But regardless of that, like, had you worked in healthcare space prior to joining Jaan Health?

[00:09:23.06] - Bryce
No. Um, yeah. So like I mentioned, I worked at a, essentially a 3D graphics startup. Um, and so a lot of my work was, yeah, completely different. So. Yeah.

[00:09:35.12] - Robby
What would you think that, you know, for those that have never worked in the healthcare space, is it as daunting as a place to work in when it comes to thinking about a lot of the data protection there? Or is actually that a lot more streamlined and kind of known, like it's easy enough to get ramped up and kind of go through training and be— I'm assuming you've needed to take training courses occasionally. We've had to do it ourselves when we have different clients that work in that space as well, just so we can provide some consulting with them for, you know, a couple months or something like that. But for those that have never gone into that environment, how would you describe that to them?

[00:10:08.13] - Bryce
Yeah, I don't think it's— I wouldn't say daunting. I mean, you certainly are going to have to sit through a lot of those training things. I mean, it happens. I do it every year. I spend basically a weekend just, you know, clicking through these little scenarios and signing paperwork that says I understand and whatnot. I mean, that's fine. It's not a It's not a big deal usually. I think in terms of the technical side of things, there's definitely more eyes on your work in that kind of critical lens than maybe you would be used to. And so I kind of see that as a good thing. It gives you more of an explicit opportunity to slow down and really consider the work that you're doing and making sure that it's secure, which oftentimes if you're at a fast-growing startup, it might not be top of mind. We use a company called Aptible, so, and I'm certainly not the person to ask on some of the platform questions. We have a team for that, but a lot of the nitty-gritty of securing the deployment and things like that are managed through a company that we work with, so.

[00:11:11.07] - Robby
I see, that makes sense. Circling back to like your product yourself, so you mentioned there's a lot of like patient communication involved in there, so how much of that interaction happens directly through the Rails app itself? And like, where does the Rails application— or is it primarily one Rails app, or is there kind of a suite of apps you have there? Where does Rails sit in all that? And through that, the communication layer of that?

[00:11:33.20] - Bryce
Yeah, so specific to the communication, I guess the way that we've architected things is like Rails is sort of a central hub API. There's a few spoke services, but for the most part, I would say I don't know, 80% of the magic happens in the Rails layer. We do have a patient web portal. Most of the communication is happening over text, so it's probably something like 90/10 in terms of what people are sending, talking about over SMS versus the web portal. The web portal is its own mini Rails app, much lighter weight. And so, yeah, for the actual SMS messaging, that's all managed through Twilio, but Rails  is kind of the orchestration on those Twilio calls.

[00:12:23.20] - Robby
Out of curiosity, was that an initial assumption that SMS would be a primary driver for most of the communication initially, if you can recall back to that?

[00:12:31.20] - Bryce
Yeah, so when I joined the company, we were actually an appointment reminder company. So it was a lot of the kind of texts that you get, I think they're fairly common these days. Back in the day, less so. So SMS was a natural, you know, it's like getting a text to a link or asking for an app to say, are you coming to your appointment, just is not that viable. But a, a very, very early pivot that we made, it was probably 6 months or something after I joined, was towards this more like care orchestration, care management. We started to notice that a lot of these front desk people were essentially developing relationships that we see and look for today with the patients just naturally. So it was kind of an emergent behavior from our users, and then we sort of leaned into texts a bit more as a result.

[00:13:22.22] - Robby
Now, I can imagine that product teams or folks from maybe a sales perspective there might be thinking, well, maybe we need mobile apps for this sort of thing. What if we just give the patients a mobile app? Had that ever come up as part of the direction there?

[00:13:37.06] - Bryce
Yeah, it's, I mean, it's something someone like most people ask for both internally and externally, and it's, it's not something that we're closing the door to by any means, but we kind of saw it as a differentiator. You know, it's one of the reasons to go with us is because we kind of embrace this approach to healthcare. If you ask our CEO, he'll say like meeting the patients where they are, you know, it's like people have a phone, They don't want to download an app. They don't need to download an app unless they want to.

[00:14:06.21] - Robby
Provide the actual tech support on like, how do I install? I can't log into my— yes, I'll be there tomorrow, this afternoon, but I can't.

[00:14:15.01] - Bryce
Yeah. I mean, I think maybe half of the phone calls I get from my mom are trying to have me troubleshoot some login to some app that she needs. Yeah.

[00:14:23.19] - Robby
Out of curiosity, with the SMS integration that you have there, what platforms are you using to handle that with? Is that something like a Twilio or something? And what are you allowed to communicate over SMS given the healthcare regulations there?

[00:14:37.23] - Bryce
Yeah, so it's all done through Twilio. All the communication, like really any data transfer that's going to like a system outside of ours, has got to be covered by what's called like a BAA. And that's like a legal agreement that just says that various properties of HIPAA are guaranteed. So things like encryption at rest, things of that nature. In terms of the actual SMS, there's like an opt-in system. So we do have to get sort of permission from the patient. If we don't have permission, you know, we sort of direct them to the web app and that covers a lot of that.

[00:15:13.22] - Robby
So now you've been working there and working on the application for about a decade. How long ago did the application start getting developed? Was that like just a little bit before that, before you joined? And what version of Rails were you was it working on when you got there?

[00:15:27.01] - Bryce
Yeah, I think it was maybe like 1 or 2 years before that. It was just the founders at that point. So when I joined, it was very early on. I think we were on, I forget the minor version, but we were on Rails 4 at the time, and we stayed on Rails 4 for quite some time.

[00:15:45.02] - Robby
How many engineers are typically touching the Rails app on say, week-to-week basis or month, each month?

[00:15:53.05] - Bryce
Yeah, so right now we've got a team of about 15 or so, and I would say pretty much all of them are touching the Rails app. There's maybe a couple that it's like less frequent for, so, you know, some of the AI folks touch it less often, but yeah.

[00:16:09.11] - Robby
Do you recall some of those early, if it was, if you started there and it was like on Rails 4, were you involved at all in the, any of the upgrades since then? And where have you been able to get up to? Are you reasonably up to date these days, if you're willing to share that?

[00:16:23.04] - Bryce
Yeah, we're reasonably up to date. So, we are now on Rails 7. We are evaluating Rails . It's very early in those stages at the moment, but definitely some interesting things there that we're looking at. Yeah, in terms of the upgrade, I would say, so we went a unconventional route, and I don't know that I would recommend the route that we went, but we went straight from Rails 4 to Rails 6 in the spring of 2020 or so. Yeah.

[00:16:58.07] - Robby
Like, there wasn't enough going on in the world?

[00:17:00.21] - Bryce
Yeah. Well, so, funny enough, for us, part of the decision was actually born out of that because we had only been in existence for 3, 4 years at that, or I guess a little bit more than that at that point. But we were still a relatively small company. There's a lot of people at the time who were skeptical, to say the least, about like the value of, uh, virtual care management and virtual care in a clinical setting. And then overnight, essentially, literally, we were swimming in business. And I think that was a big part of our decision to make a big change at once. I think this is probably true of a lot of companies in the early stages. We were a bit of a, you know, Frankenstein of gems. We were just trying to ship features, trying to find product-market fit, really. And as a result, we were looking at our app saying, like, we might only have one chance to do a bigger change like this. It's very quickly gonna become the kind of thing where, this turns into a 6-month project versus, you know, just rip the Band-Aid off, deal with the fallout if there is any.

[00:18:10.12] - Bryce
And yeah, so that's the— that was the direction we decided to go.

[00:18:15.00] - Robby
So when it came to the upgrade itself from 4 to 6, and maybe you wouldn't recommend that necessarily going down that path, uh, do you recall why that was a challenge for you? Or, and what sort of things kept you in that 4 era for as long as you 'Cause 2020, trying to remember what was out then, but I feel like 7 was kind of close to coming out around then, give or take.

[00:18:37.09] - Bryce
If I remember correctly, I think it was like 6 had been out for maybe half a year or something.

[00:18:42.21] - Robby
Okay.

[00:18:43.01] - Bryce
So it was, 6 was the latest version at the time that we changed. But yeah, I think probably the blog posts had started coming in on 7, you know, but Yeah, in terms of what kept us on for so long, I think that a big part of it was, I guess, like I said, we were a very small team at that point. There was not a lot of, I guess, appetite for paying down some of these tech debt things. I'm trying to remember what Rails 5, maybe was ActionCable was the headliner, if I remember correctly. There weren't a lot of things that we were eager to jump ship for, and it was kind of just the inertia of, If it isn't broken, don't fix it.

[00:19:28.12] - Robby
How would you have rated your automated testing situation at that point in time? Was that a blocker at all or become a factor at all?

[00:19:36.16] - Bryce
Yeah, it was certainly poor, and that's one of the reasons why I wouldn't recommend it. Yeah, at the time, I think it was, like I mentioned, we were using a lot of gems. We used this gem called Mailboxer to represent Conversation state, but it's really a gem designed to handle email and whatnot. And so, a lot of the upgrade was kind of, we almost treated it like starting over. It was like, we have one opportunity that we're gonna have to rewrite things. And so, we gutted a lot of the existing application and just wrote it from the beginning in Rails , which made it a little bit smoother.

[00:20:17.18] - Robby
Looking back, what decisions do you feel like aged surprisingly well?

[00:20:21.15] - Bryce
That's a good question. I think that some of the decisions that aged, I mean, certainly just getting on to the latest software was a, it made conversations around security, things like that go much smoother. So that was a win in general. I think a lot of it that has aged well was owning the fact that, like, I think gems are great, we use gems all the time. Once you reach a certain level of maturity as a product, there can be a lot of over— or not over-reliance, but like, the gem becomes, you know, you start to torture it into these shapes that it was never really designed for, if it becomes too load-bearing in terms of— So, I think the decision to bite the bullet, take this Mailboxer gem, which we weren't We weren't building an email platform, and just design some proper models, take some inspiration from the parts of it that we liked, and ship our own architecture. I mean, it's the same architecture we still use today, so I guess it's aged pretty well.

[00:21:28.02] - Robby
Do you feel like your team now thinks differently about how and when to bring in an external dependency, like a different gem that's not bundled in Rails, versus how do you think about picking one or not versus being influenced by one and then be like, "Let's kind of own this ourselves."

[00:21:43.09] - Bryce
Yeah, honestly, in the age of AI, it's an interesting question to consider, because I feel like that's almost added a whole nother dimension to your decisions.

[00:21:53.00] - Bryce
The team definitely thinks differently. I think at the time, it was very much trying to compose from well-tested, well-understood, well-documented pieces of code. There's still a preference towards using gems when, combination of the problem that you're trying to solve is truly a commodity problem. I mean, we're not writing our own auth layer or anything like that. And then maybe the other axis being when the gem itself has a decent amount of, you know, either community activity, it's relatively well-maintained, you can kind of, I don't know, I'm a big fan of One of the best ways to learn how to code really any language, but especially Ruby, is to just poke inside, look around, and get a sense of like, is this well-written code? Do I like it?

[00:22:45.10] - Robby
I can appreciate that. So kind of like dive a little deeper into your, your Rails app, you know, and from what I kind of understand is that you have like a primary, is it kind of like your primary API app? And you mentioned you have kind of like a portal app that interfaces and is it, it sits in front of it and then is that correct?

[00:23:05.02] - Bryce
Yeah.

[00:23:05.23] - Robby
So what's the architecture of that look like? Are you relying a lot on just like default Rails API approach or is that like JSON APIs?

[00:23:15.02] - Bryce
Yeah. So we're, we treat the, the Rails app is just an API at this point. Um, so we, and we use, you know, API mode and whatnot. All our front ends are built with ActionView, but in terms of, yeah, the data transfer between the two systems, we do sort of an interesting, it's almost a take on the Rails philosophy of thin controllers and fat models. We took that almost to its logical extreme, I would say, where a lot of our APIs will route through a singular API endpoint, and then we created this thin abstraction layer that We call them action responders, and those are responsible for handling a lot of the data serialization, kind of giving a shared access pattern, whether you're calling an endpoint through an HTTP request or even potentially having code that calls code, like from a service. You're gonna call with the same arguments and whatnot, and then that all goes through, returns kind of a standardized, normalized payload to the frontend to be more possible.

[00:24:25.17] - Robby
Do you recall any of the conversations around when you decided that you would not also have much of the frontend be in Rails itself? You mentioned like there's a Rails portal, but like if you have a bunch of Vue frontends, was that, what were some of the decisions? Do you recall what that kind of rationale was at the time?

[00:24:43.22] - Bryce
Yeah. Um, it's a good question. I think a lot of it. Came down to, we were using a lot of HAML, so we did a decent amount of, pretty much all of our views were server-side rendered. We were on Rails 4, so we started to get some questions about reactivity that we didn't have great answers for because there weren't as much things like ActionCable and whatnot weren't part of the stack. But ultimately, I mean, in a lot of ways, I think we decided on Vue out of a, Similar to our decision to go with Rails , I would say, I like the approach that Vue was taking at the time, this idea of these single file components. It really resonated with us in a lot of the ways that some of these principle philosophy to development, it felt like they had a really strong perspective on how front end should be written. And so that was something that we were excited about.

[00:25:45.06] - Robby
Do you feel like if you were starting to build this product now, you would approach that differently now? Not saying that it was wrong or right, you know, obviously, but like right now, do you feel like the tooling feels more appropriate for that sort of requirement? Because I do remember that era of like, wow, there's a lot of Rails apps that were primarily APIs. We worked on a bunch of those at ourselves, at our consulting company. And when we're trying to figure out like, oh, this seemed to be kind of in vogue at the time, understand that that's the kind of like how things kind of shift around a little bit. Do you remember, like, yeah, maybe to start off with that initial question, you feel like, how would you think about that now with what's available in Rails ?

[00:26:26.01] - Bryce
Yeah, it's definitely something that I'm curious about. It's another one of those sort of inertia questions. It's on the front end, I think, especially, you know, code can really start to get much bigger quicker. If I were to start today, I think I would certainly want to try what the latest Rails, I mean, the idea of just having one stack is kind of, there's an elegance to that, is appealing. So I haven't played around with it as much, some of the latest changes to Rails, but I think ultimately that philosophy of declarative programming on the front end, that seems to have become just industry standard. Like, there's very few— nobody's really writing jQuery frontends anymore. Sure. Yeah, so I think I would be interested. I don't know if I would go— I would at least try it out, I guess.

[00:27:19.23] - Robby
Hey kids, are you ready to get on Rails? Now you can bring the power of Ruby on Rails online straight to your home computer with the Ruby on Rails 1.0 Edition. Just pop in our free CD-ROM and get 40 hours of Ruby on Rails delivered right to your door. That's right, 40 hours! Build forms, ship CRUD, generate scaffolds so fast your family computer gets warm to the touch. Featuring classic Rails 1.0 favorites like ScriptGenerate, rake db:migrate, and beautiful server-side rendering. The way nature intended. And finally, you can build that family budgeting app and chore chart you've been meaning to get to. So don't wait! Pick up your phone, dial the number on your screen, and get your 40 free hours of Ruby on Rails  on CD-ROM. Call now! Not compatible with Adobe Go Live or Microsoft FrontPage. Requires compatible computer, compatible patients, and one working phone line. Some assembly required. CD-ROM does not include security. So at least go back to the, the API thing for now. I'm curious about, is it fairly REST approach, typical Rails REST API? Um, I've talked to a couple different people that have done some interesting, curious things that I don't say is wrong or right about that, but like where they've had some more complex approaches to how they've thought about their APIs.

[00:28:28.00] - Robby
But are there external consumers of the API or is it all primarily just your team? Like, is anyone building their own apps, like customers that are interfacing with your APIs?

[00:28:38.02] - Bryce
Yeah, so not currently, but it's something that is, it's one of our biggest requests, you know, especially from some of these bigger health systems that have their own IT teams and whatnot. And they're like, hey, can you just give us an API key and we'll build what we want to build. We haven't gone that way just because it's a whole nother can of worms of security that we haven't prioritized tackling yet, but I think it's in our future for sure.

[00:29:07.07] - Robby
Are there any other really interesting things about your application? Like if someone were to start working at John Hill tomorrow and it was also going to be, say hypothetically, your last day and you had 30 minutes to give them a quick download of like, Hey, it's pretty typical Rails  API backend, but you might want to know about these few little weird things before you don't get to ever talk to me again.

[00:29:30.22] - Bryce
Yeah, no. So I would, I hope that our documentation is in a place where some of that would not be necessary. But I think if I were to pick like one thing, it sort of alluded to it earlier on, on this, this, this concept of an ActionResponder. So, it's definitely bespoke, but I do think it's built in the spirit of Rails, I guess. So, I would sort of explain it like, "Hey, this is basically a controller. It's just a controller that lets you make sure that all of your sort of, you don't have to worry about sort of data serialization, you don't have to worry about some of this, like, standardizing your parameter parsing and things like that." All of that is taken, stuffed into this layer that's called an ActionResponder. And one thing that's really interesting that plays nicely, I guess, with, you know, especially some of these, like, declarative frameworks, like Vue or React and whatnot, is that because we're using JSON API, the end user can request, like, sparse fieldsets and associations and whatnot. And kind of out of the box, you know, any endpoint that is built using Action responders, they'll respect this interface where if the user just wants a response with one field, it's a little bit like GraphQL in a lot of ways.

[00:30:53.09] - Bryce
That's what I was curious about, yeah. Yeah. Which we did evaluate before we committed. It was a big decision of, okay, do we want to just go with GraphQL? And ultimately, I think the decision that we were making there was that it felt like GraphQL was It was a lot of overhead and we didn't need a lot of the features. And at a certain level, it just didn't feel like the Rails  way to do it in a lot of senses. We were like, we don't really need all these things. We really just wanna make it so that we can take some of this logic that's sitting in these controllers and rather than shipping it off to this litany of service objects or whatever, put them closer to the model.

[00:31:36.11] - Robby
How do you organize a lot of your business logic in your application, out of curiosity? You mentioned service object. Do you lean on that much?

[00:31:43.09] - Bryce
So, we certainly use service objects. I think that what we noticed before we made the shift towards action responders was that our controllers had largely become wrappers around the model, and there was a lot of these service objects living around that were more or less responsible for the same types of things.

[00:32:02.06] - Robby
Can you give us an example?

[00:32:04.16] - Bryce
Yeah, a lot of it was around parameter parsing, some of it around, we use Pundit for authorization, so stuff around authorization was getting repeated all the time. And you can imagine authorization's kind of a big deal in our environment. And so, we started to see that almost like, it was almost like a necessary evil, I guess, of like, you have to do all those things. A lot of times you do them the same, but there's not a, abstraction that pulls out the generic parts from the parts that are specific to a given model. And so that, I think, is what led us down that path initially.

[00:32:46.22] - Robby
I'm curious about this action responder, and your action responders there, and this concept there. So it's approaching, in a way, trying to dry up maybe some stuff in your controllers in that sense. Do you feel like that's added, if someone joining the company, like that abstraction layer is easy enough to wrap your head around? Like there's some consistency there. Do you feel like it's, I'm assuming that was like somebody's clever idea and like, like, yeah, that sounds great. Let's all do this. And we don't have to have a bunch of the same things showing up in different parts of the application. Um, how does it feel like actually living with that day in and day out? And regardless of whether or not you think that was like a good idea or not, but it's like. Do you feel like it's been a really helpful, benefited, added thing that you feel like it's something missing in Rails, or do you feel like it's just something that was part of how your team solved an interesting challenge that you were seeing?

[00:33:39.11] - Bryce
Yeah, it's a good question. I think missing in Rails might be a bridge too far. I do think a gem that I could see a lot of people potentially being interested in using or something like that, that feels more like in that category. But I mean, overall, it's It's a decision that has paid a lot of dividends over the years in terms of executing, building quickly. It's our own thing, so there's always gonna be a little bit of overhead of teaching people the patterns and whatnot like that, and maintaining documentation. But for the most part, I think it's really solved a few problems. One of the most interesting ones, I guess, has been in the testing layer, actually. So, I mean, we still use Factory Bot, we write factories, but what we, There's a lot of cases where we noticed that when we had a test or a situation, like a bug that came up, we looked at the test, all the tests looked fine, and part of the reason that the tests were fine was because we were in this stub hell of just this hyper-idealized state of things. It didn't really reflect all the messy, maybe side effect logic or things like that, that get triggered.

[00:34:51.12] - Bryce
We were finding ourselves building these, like, bespoke seed files or fixtures or whatever to try and capture some of that. Once we switched to Action Responders, from a seed file, you can call, like, just as the same, and it almost marries some of these integration tests, right, where it's, like, the exact same code that would get run if you sent the request over network, you can just call directly from the backend, and there's no difference between, like, it's all the same parameters, go get parsed the same way, any side effects that get triggered. So, suddenly, it became very easy to create pretty complicated, you know, situations just through, like, a series of, okay, then this was called, this was called, this was called, and now I can kind of guarantee I'm in this state of the world.

[00:35:39.12] - Robby
Sure, sure. What sort of tooling do you have in place for things like observability or monitoring things? How does your team diagnose and debug issues right now that might be popping up in production?

[00:35:52.11] - Bryce
Yeah, so we use Datadog primarily. That's like our main APM. The host provider that we use, Aptible, they have some tooling as well. But I would say, yeah, most of our diagnostic stuff happens in Datadog.

[00:36:08.16] - Robby
You know, it's like we're recording this in the middle of May 2026. And so like there's a lot of AI tooling out there and we can dig a little bit deeper. I'm curious if you've been able to leverage much of that within using, with interacting with Datadog and the tooling that they're providing at this point to help you debug things quicker or anything like that. What's your experience actually been like on the ground?

[00:36:30.13] - Bryce
Yeah, no, that's a good question. I think Datadog has been, I haven't used much of Datadog's native tooling, I guess, but just the ability to take, I don't know, this happens even just during development, Using some tooling to understand stack traces, it feels like the almost ideal case of what AI can do in terms of taking something that, yes, I can do it, it's tedious, I just manually go through and check line by line by line, but then to have that just instantaneously so that you can focus on that higher-order thinking and not just what code called what code, which ended up in the problem state. So definitely having some of those, like, Trace deep dives and things like that.

[00:37:17.12] - Robby
So an application that's been in development for 11, 12 years, and you've been there for over a decade or so. So every application tends to eventually develop a few scars, maybe, to say the least. So I'm curious if you could talk a little bit about, say, operational, the operational reality a bit. I remember when we had a previous conversation, I think there were some topics that came up related to background processing, kind of, you've had some issues over the years. Tell us more.

[00:37:45.16] - Bryce
This is a problem that we really, it actually came up kind of recently, but it's been, you know, especially as we've grown, we've seen it, we've been kind of monitoring it for a while, but we use Sidekiq for all our job processing. We have a pretty, a pretty bursty peak of usage, I would say. So our app sends, People through our app will send on the order of 100,000 Twilio messages a day, and those are all managed through our background. Those are all on async jobs so that they can do the proper, like, retryability and things like that. And so, the thing that had been coming up recently, the job queues themselves were relatively healthy with some caveats on our SLA. We gave ourselves a fairly generous SLA, I guess, Within, we weren't exceeding our SLA, but what we noticed with some of these, like, really, you know, big, bursty use cases was that the end-user experience of the queue was very different because of the way that we were enqueueing our jobs. What was happening was that one person would log in, they would, you know, maybe queue off a set of messages to call it, like, 500 patients or something like that, you know, and then the next person would log in and they would queue up their 500 patients.

[00:39:09.06] - Bryce
And so the first person, they would see those 500 messages and they'd start getting replies earlier, but while the queue was being processed, and the real numbers are quite a bit bigger than 500, you know, and so that, that second person is basically waiting for the entirety of the first person's, uh, process to finish. And so, there were a few things that we did, but I think the biggest sort of change was we changed the way we were, like, treating those batches. So, rather than having, you know, like, a batch that spawns a bunch of underlying jobs, and you have to wait for the batch to get picked up, you know, we immediately moved the batch to, like, all be on the same queue, to have the batch, in queue quickly. And then the next thing that we did was we sort of broke up the jobs so that the first 100 of a given batch, regardless of how big the batch was, put that on a very fast queue so that everyone will sort of get the feeling of, you know, responsivity. Even though, you know, if you're trying to send 10,000 messages, the 9,000th message might not send for an hour and it's waiting in line, but you're not sitting there waiting because someone else tried to send 10,000 ahead of you.

[00:40:28.06] - Robby
That's interesting. I mean, is this just a matter of like you just needed to have more parallel queues type of thing? Like how do you think about these things? And does Twilio, are you bumping up against any constraints that Twilio might have for you? And do they treat those separate for each? I'm assuming like if one— I'm just trying to wrap my head around this— but as far as like if you have one doctor's office, say it's some people working there, and there's another doctor's office, like are they all through Twilio going through one account through your, your organization, or do they have their own like individual things? So you could in theory, like, do they have any like caps or anything like that that also come into play into this?

[00:41:07.02] - Bryce
So Twilio does have sort of like a multi-tenant setup where— so we have a dedicated each account, each doctor's office, will have their own dedicated Twilio instance. I don't know how they do it on the backend, but they call them subaccounts, basically. So they're all, yeah, subaccounts. So in terms of rate limiting and stuff, usually we haven't had many issues, because I think the rate limiting limits are really at the, each subaccount has its own rate limit. In terms of how we start to, bump up against this, the splitting on our side, I guess. Maybe this isn't the direction you're imagining, but like, are you, are you kind of asking about like almost like our queue topology?

[00:41:51.20] - Robby
Well, it was just kind of like a little bit of that, and I think just a matter of like, it's an interesting thing, or if you got several people at this approximately the same time trying to queue up things and then trying to like make sure their experience is like they're not waiting because someone else just triggered a similar thing. How do you, do you feel like you found a good happy path with that at this point? Or what sorts of things are you still navigating as far as like, is there a better way to orchestrate that sort of thing so that it does get through them quicker? Cause I'm, but I guess they, I guess there's also a challenge, like you're maybe from a user perspective of a nurse practitioner or whoever in the office is sending out 500, a blast of 500 SMSs. Um, And they're probably maybe not ready to start getting 500 responses right away either too.

[00:42:35.09] - Bryce
Yeah, no, exactly. That was actually the last point you brought up was a big part of our decision is because we had sort of kicked the can of just increasing number of workers, increasing the capacity of those workers for a while. And then we did reach a point where we started to ask ourselves, is this even the right problem to solve? Are we not thinking about it from from exactly that lens of, like, maybe it's actually better to have these kind of naturally spaced out and not make the user really think about, you know, like, I know I wanna message these people today. I don't necessarily need to message them at 10:06 AM. And so, in terms of our happy path, I think there's a really great article, I think Judoscale, it's, like, a blog post by Judoscale about queue naming. and it totally changed our philosophy, 'cause we had been doing sort of just an ad hoc, like we had an import queue, and a real-time queue, and a low queue, and a default queue, with weights that had just been sort of tuned in this ad hoc way. I'm sure, probably a familiar experience for a lot of people.

[00:43:43.22] - Bryce
But this post talked about naming your queues with the SLA. So now our queues are all, we have, like, a within 5-second queue, we have a within 5-minute queue, we have a within 30-minute queue, within an hour. And so it's just really great because you can set up, you know, you can set up your Datadog to, like, trigger an alert of, like, oh, your queue SLA is not being respected anymore. And that triggers you as a developer to go investigate, like, oh, are we putting too many jobs on the queue? Are we, you know, do we need to increase the processing power? Or is it that there's some job really doesn't belong on that queue, we could shift down a layer. And as a developer, it's great, because I mean, I get so many fewer questions being like, should I put this on the import queue or the default queue? Because it's just like, the question almost answers itself. It's like, well, how fast do you need it to be done? What's the user expecting?

[00:44:39.21] - Robby
That's interesting. Yeah, I just pulled this up, this article right now. So for our listeners, yeah, it's like isolated. Their examples are like 5-second worker, 5-minute worker, 5-hour worker. And then kind of like some scaling config options there as well. No, that's helpful. I'll try to remember to include a link to this article from Judoscale in the show notes for our listeners as well. So you're using Sidekiq there and how often are you needing to debug anything that's happening in that processing?

[00:45:05.02] - Bryce
I don't, I wouldn't say that often at this point. It was certainly when there were some early some growing pains, I guess, where we just hadn't really given, we never needed to. It was like we had a small enough volume of jobs, so queue, we didn't think about it very much. And especially since making this change, it's been much more straightforward.

[00:45:28.15] - Robby
How would you say Rails  is part of John Held's secret sauce, so to speak?

[00:45:35.11] - Bryce
Yeah, I mean, to me, I'm sort of biased. If you ask other people at our company, they might not have, they might think their job is more important. But because it's my job, I think it's really a big part of our secret sauce, especially, I mean, a big part of our, you know, vision is to not just use, you know, AI tooling for our own purposes, but also to start to use it for to help, you know, assist care managers and whatnot in their daily workflows. And I think the Rails  has provided a lot of the sort of, just a framework that we can rely on and not ask questions that are getting in the way. It's a space that's moving super quick. You always feel, if you work at an AI company, you always feel like, oh no, someone's gonna vibe code my app in a week or whatever. There's always this sort of background pressure. So knowing that we're not spending our time thinking about how to build something technically excellent and worrying about all the security things and that we can just take a lot of that for granted and focus on the problem in front of us, the thing that actually makes our company, our app, our product unique is, to me, the whole secret sauce almost.

[00:46:53.06] - Robby
That's great. How often is your team deploying updates to your to production?

[00:47:00.17] - Bryce
We do nightly builds, but that doesn't always— it's sort of, we push to sort of release branches, and so we don't always merge everything that's ready nightly. But yeah, we use GitHub Actions to manage a lot of the deployment infrastructure. But I would say probably, it depends on what features are the most critical, but usually, on the order of we're shipping stuff probably twice a week.

[00:47:30.09] - Robby
How does your team approach developer onboarding and how do you navigate trying to have realistic data to debug and test things in a local developer environment or staging QA environments and stuff like that?

[00:47:46.00] - Bryce
Yeah, I mean, it's definitely one of the biggest challenges. So we have a dedicated staging A staging app that is basically a faithful recreation of the true prod environment that's hosted in all of our most secure infrastructure. It has all the protection and whatnot, but that's not something that, you know, it's more of a break-in-case-of-emergency kind of place to go. So, in terms of getting newer folks onboarded more quickly, I think that we rely a lot on some of these seeds. I think maybe that's also part of why some of the seeding stuff is, is so critical for us, because, you know, it's a lot of these relationships are long-lived. There's lots of— it's not very helpful to just get a patient with no data in them. Um, and so it's definitely an area that we're working on, I would say, improving at this point. But for the most part, when we're testing the last little bit of testing, if it's something where we expect that there's at least some risk of failure just from the fact that the true production data, we'll do our last round of testing and CI on that pre-prod environment.

[00:49:01.23] - Robby
I see. What does that testing process look like if you're, not saying primarily, but a large part of it is sending out a lot of SMS messages and feeling pretty reliable? How do you verify that things are working as smoothly knowing that the jobs are getting closed off, but how do you test that before you ship things to production? Because you're not able to just push it. Are you relying on a lot of VCRs?

[00:49:23.12] - Bryce
We rely on a lot of stubs and mocks, I guess, of certain endpoints outside of our system. We do have a few. So it's a really great feature of Twilio, but they have dedicated testing phone numbers.

[00:49:40.06] - Robby
Oh, yeah.

[00:49:41.15] - Bryce
Hook up things to a sandbox account that has these dedicated testing numbers where if you text this number, it will say, "Oh, I'm a landline," or something like that, or it'll give you the actual response. So for that layer, we sort of centralize our tests into, we have one part that tests all that, and then we have some integrations. We use Playwright for our full end-to-end integration tests, where usually we'll only run our Playwright against Not a mocked environment where those external connections are just stubbed out. Occasionally we have it as an environment variable flag to instead run it against an environment that's deployed pointing at that Twilio sandbox.

[00:50:28.08] - Robby
I see.

[00:50:28.17] - Bryce
I see.

[00:50:29.01] - Robby
That makes a lot of sense. So another thing I wanted to touch on quickly with you is without turning this into an AI episode, I'm trying to not do that necessarily, but A lot of teams are, and we touched on this earlier, are trying to figure out how this kind of fits into their day-to-day logistics. So what sort of experiments, conversations is your team having right now about how to, around like say AI-assisted development?

[00:50:53.11] - Bryce
Yeah, it's a really, it's a big thing we've been working on a lot recently. I think like we're still, maybe we're just starting to graduate out of this zone of, you know, people doing whatever they want, some people doing things one way, other people trying to do them another way. I think the part that has really started to solidify at our org is this idea that, it's a favorite phrase of our founder, that our job is to give people superpowers. And normally we had thought about that in terms of the products that we build, but now it's starting to happen in terms of how can we supercharge developers, and the use case that I guess we've landed on is trying to take a lot of these features that are maybe smaller, maybe, like, the kinds of things that often sit in the backlog for a while. They're a good idea. There's maybe not, like, a strong advocate for them. Giving developers the power to take something that is maybe just a vague idea or, like, a loose set of requirements and turn that into a feature in a way that our product managers would sign off on, all of the different things that were involved.

[00:52:06.00] - Bryce
And so we've got a set of, we use Claude Code mainly, but a set of skills that go through a pretty rigid pipeline at the moment where the first step that it will do is it generates a PRD from, you give it a description of what you're trying to do, or if there's a ticket for something, you can copy-paste the ticket. And then it gives you a PRD that you can take to a product manager and be like, "Hey, I think I want to build this. Does this look like the right set of requirements or whatever?" And then it goes through this pipeline where it builds an FRD and then a technical document that is an implementation plan. It ultimately ends up at a set of And at each step along the way, our expectation of our engineers is, "Hey, you guys are smart. Read through it, refine it, try and do the same things that your PMs would do, that anybody would do looking at this." And then it ends up at a test suite. So, that's one kind of critical component of how we're choosing to approach this is that rather than having it, For small things, if it's a small bug, sure.

[00:53:23.18] - Bryce
It can be just, all the rigmarole isn't necessarily required. But for these features that are maybe 3, 4 days' worth of effort, we try to make sure that the developer that is really signing off on, these tests make sense, these tests are the correct way to prove this feature before you actually have the LLM write any of the other code. And so, yeah, it's been a really interesting, it's been very powerful in terms of that, give engineers superpowers. We've seen engineers really create pretty complicated features, things that, in the front end, the backend, maybe involve a lot of complex requirements, just on their own, with very little involvement from a lot of the other players that you would usually have involved.

[00:54:15.11] - Robby
What I find interesting about that is like, I've had a lot of conversations. Again, I work for some context, I've worked in the software consulting side. So companies are coming to us and we're talking with a lot of, a number of different companies right now where they're, they're trying to kind of move more of that type of work a little bit more upstream and like giving like their product owners, so they can do a little bit more experimenting within the codebase and their own little sandbox version of it. And that way the engineers can focus on the things that they need to be focused on. Like, oh yeah, you can, you can move down your path. It sounds like maybe you're there, the engineers are taking a little bit more of that initiative and taking on more of the, maybe that, I don't know if that speaks to like the size of your company or just kind of like the culture there or.

[00:54:57.15] - Bryce
I think it's a little bit of both. So we certainly have, I mean, I think in this past month, almost all of our PMs officially have GitHub access and have been their own environment set up. So we're definitely approaching it from both sides. I think that what we, I guess, have strategically decided is that the more that we can have the PMs focus on some of these bigger picture things, almost feature-level or epic-level work, that's where their time is going to make the biggest difference, in that you really need to take in a wealth of information from the outside world, from customers, from, in our case, a lot of regulations, things like that. That's where they need to, we wanted to almost put most of their time on that rather than, hey, there's this UX flow that's clunky and maybe there's a better way to do it, or there's this page that loads slow and really we want you to That's the work that oftentimes what we've found is it's natural fits for both. It's stuff that we found the engineers were bugged by the most, and they were often saying, "Why can't I ship a fix to this thing that I know is broken?" And the PMs were saying, "Why am I spending all this time working on these things that just sort of make the system a little bit better?" That makes sense.

[00:56:25.07] - Robby
So kind of allowing both of those sides to take on a little bit more ownership and turn things around a little bit quicker, potentially experiment quicker. Do you, you mentioned that, you know, given that your app, you know, you're using Vue for a bunch of your frontend, are those in separate repositories? And then how is that kind of all being, are those all kind of used like a monorepo type of approach? And is that, or is that something you're currently reevaluating at all given LLM usage?

[00:56:50.23] - Bryce
Yeah. So right now they're split out into two different repositories. So we do have a, basically like a VS Code workspace so that anything, like if you're running Claude Code or something, then you're able to, you know, do that full stack development in, you know, one pass. If you're writing something that touches both front end and back end, you don't have to. Yeah.

[00:57:15.13] - Robby
All right. So you're in that space where you're working on through a commit that it needs to touch two different repositories or maybe three. To ship out a new feature, then it can orchestrate that pretty seamlessly. I feel like 4 or 5 months ago, that felt like it was more of a challenge for teams.

[00:57:33.14] - Bryce
Yeah. Yeah, no. And it's funny, so all those skills, I mean, we have a wrapper top-level repo that's really just a registry of all the underlying repo, and that's where all those skills live anyway.

[00:57:48.04] - Robby
I was talking with Brian Scanlan from Intercom, now known as Fin, I think they just announced it yesterday, so I'm just trying to remember to say that. But they were talking about how they've added a lot of observability and monitoring of how those skills are being used. Have you, have you explored anything like that as of yet?

[00:58:07.18] - Bryce
It's possible that someone other than me has, but I wouldn't say it's still in the early days of development. We really, I think just in the last sort of couple of months, handed it over to some of the engineers. For a while, we had a few engineers trial it, give feedback, and whatnot.

[00:58:27.05] - Robby
Can you think of a recent thing that you've done with Claude Code where you're just like, "Wow, this works really well within the Rails workflow"?

[00:58:35.19] - Bryce
Yeah. One thing, I guess, that I worked on pretty recently, which I was like, because I wouldn't say I was an AI skeptic, but I certainly wasn't, you know, an AI booster for a while. There was a lot of times where I was a little bit like, uh, it's good for scripts, it's good for SQL queries, you know, but I don't want it to write my application code. That's my baby, you know. Um, and something that I worked on recently is just like a, a fairly complicated, um, like a business processing model. So, you know, think like Zapier, Flowize, like some of these, or like a Lucidchart, just a way to build flowcharts. It's a big part of healthcare, right? Like where you have these decision points, you need to be able to generically represent these things. And I mean, there's a long evaluation period and there's a certain point I kept thinking like, well, I can't build this. I don't want to build this, other people must have built this better than me. And then I wasn't finding the answers I was looking for. And as a last ditch effort, I was like, okay, let me just sit down and really describe exactly what I need, exactly what I do and don't like about all these different options I've looked at and see, hey Claude, let's try and build something on this.

[00:59:58.05] - Bryce
And it was a pretty impressive result. It The models were pretty clean. It certainly understood, in terms of Rails patterns, the idiomatic way to write Rails, which I think for a long time was one of the things that I felt was lacking a little bit. So, yeah, and it's something that I shipped much faster than I think I would've shipped otherwise.

[01:00:26.15] - Robby
Where do you find that boundary right now? Do you feel like someone that's not a developer would've been able to get to there? On their own without you being part of that workflow? I'm just trying to speak to the, uh, are you worried about your, your role as a software developer in the community? Because like, hey, the tooling is getting like, or do you feel like because you have that, that domain expertise to be like, ah, this is what you're evaluating different options. You can kind of like tell, like it can't quite solve these types of problems, at least as of yet.

[01:00:54.15] - Bryce
Yeah. I mean, it's, it's definitely a, like an existential question right now, but, um, The way I see it, there's this essay I really love that's called "Programming as Theory Building." I don't know if you're familiar. It's by Peter Naur. I think it's from, like, the '80s or something, maybe the early '90s. It's this old idea, and it's talking all about this concept of why programmers, like, essentially, why you can't just throw more programmers at a problem to, ship it faster. And the takeaway that, I guess, or, like, the argument that he makes is that the job of the programmer is not to produce code. Source code is not the output of a programmer. It's the theory of the source code. So, this idea that, like, your job is to build a theory that is, you know, a good theory for handling the kinds of problems and, like, The code itself is just this consequence of, like, it is just an implementation of that theory. I think that, I mean, for me, it's like, only as the production of code becomes even more commodity, to me, it's just more about, like, it's giving you the tools to really do what you were always supposed to be doing anyway, which is crafting that theory, thinking about, like, what that actually entails, what are the interfaces, how can you build this in a way that makes it effective and usable, maintainable over time?

[01:02:35.12] - Bryce
And the more that you can give the actual writing of the code, and it's a big part of why we're so in favor of using tests is because the test suite almost becomes the theory of the code. It's like, "Really, this is what we're describing." That resonates.

[01:02:52.14] - Robby
I'll look up that article, see if I can include that for our listeners as well in the show notes. I, I'm kind of curious, do you, do you know kind of the backstory on why Rails was chosen in the first place there?

[01:03:06.05] - Bryce
Um, only a little bit, I would say. So our founder, he had previously worked at some Y Combinator places and he was, he was someone who was very much in like the startup scene, I guess, in around the time that Rails  was becoming, came out and became popular. So I think for him it was, and just knowing him, I guess, for 10 years, he really embraces just the philosophy that goes into it.

[01:03:35.10] - Robby
I see. Are they a developer as well originally?

[01:03:38.09] - Bryce
Yeah.

[01:03:38.23] - Robby
Okay. So it was part of one of the tooling choice that was made at the time. And I know still a lot of Y Combinator companies are still choosing to use Rails . So that's great. Um, all right, Bryce. Well, I feel like I've kept you long enough, so I'm kind of curious for, for some advice for our listeners. So as you reflect on choices and decisions that your team has made, what's one technical or team decision that your team has made that you think our listeners would probably benefit from also maybe considering as well?

[01:04:07.06] - Bryce
Yeah, it's a really, it's a tough question because it really depends on what your demands are. I don't know if it's a technical one, but one that comes to mind is, you never need as much as you initially think. I think that's one thing that I've learned the lesson on a number of times. And it's very easy to sort of talk yourself into certain use cases, like, as programmers, we're inclined to think about edge cases. Inclined to try to overbuild in a lot of cases, but just trust that what you actually need will emerge from what you ship. And if you have that faith, it will come.

[01:04:55.04] - Robby
That resonates and kind of speaks back to the topic earlier around how we look at and evaluate gem dependencies and things like that, what we're going to pull into our app. And you mentioned table stake things like maybe authorization or something like that. Like maybe we don't need to, maybe we can rely on the, the community to provide support for this thing, but maybe something you mentioned like that other business modeling thing that you did earlier, maybe there's things you looked at and evaluated and you're like, well, we have a very unique thing. Let's not try to adapt our business model to fit a generic problem pattern that the community's been solving there. So I think, I think that's helpful. Out of curiosity, is there a software book that you found yourself recommending? Piers, lately?

[01:05:36.10] - Bryce
Not as much. So I came from the math background, so I wasn't as steeped in the books. I guess I will say, I do think one thing that's maybe a hotter take, especially these days, is one of the best ways to learn programming is to really sit down and force yourself to learn C at least once in your life. I think it really helps you Especially in the age of AI, I see it as this, like, layering of higher-order thinking of, like, going from assembly to managing memory to, you know, these more expressive programming languages to now, maybe you're not really thinking as much about even the programming language layer. I mean, maybe I've never written assembly, maybe I'd feel that way about assembly, but at least going down to the level of C gets you really familiar with, like, how a computer thinks, and that can be really, really helpful. For building out your intuition about debugging, about systems, about what works and what doesn't work.

[01:06:32.06] - Robby
I think that's some reasonable advice for our listeners there. And maybe with AI, maybe you can do that a little bit quicker now. I don't know, but this may be worth an experiment there. Does the Jaan Health have an engineering blog or anything like that we can direct people to?

[01:06:47.09] - Bryce
No, I think we post some stuff on LinkedIn every once in a while. So yeah, people can find us there or phamily.com is our sort of marketing website.

[01:06:58.17] - Robby
That's family with a PH, right? Yes. Phamily with a PH.

[01:07:02.15] - Bryce
Not the best name for a podcast, I suppose.

[01:07:05.03] - Robby
Well, we'll include links for that in the show notes for all our listeners. And with that, Bryce, thank you so much for stopping by to talk shop with us on On Rails .

[01:07:12.10] - Bryce
Yeah, thank you so much. I appreciate it.

[01:07:17.00] - Robby
That's it for this episode of Ruby on Rails. This podcast is produced by the Rails Foundation with support from its core and contributing members. If you enjoyed the ride, leave a quick review on Apple Podcasts, Spotify, or YouTube. It helps more folks find the show. Again, I'm Robby Russell. Thanks for riding along. See you next time.