Podcast Episode 9: Episode 208: What Vibe Coding Means for Rock Churches

Description

In episode 208 of Rock Cast, Jon and Emily tackle a hot topic in tech right now, vibe coding, and explore what it means for church software and digital ministry. As AI rapidly reshapes how software is built, some are asking whether traditional software is becoming obsolete, but what does that mean for churches?Listen to the complete episode to hear their discussion and visit the show notes to find the resources they mentioned.

Transcribed Content

Welcome back to another episode of Rockcast. I'm Emily Forman and Jon Edmiston is joining me today. We have a full list of topics to talk about. We're going to cover the latest updates, bits and bytes with Rock. We're also gonna talk a little bit about that topic that's taking the Internet by storm, Vibe coding, and some thoughts about that. We're gonna chat a little bit about early access. That's a topic that's come up in the community recently, and then we'll have some community announcements for you. So let's kick it all off with that update on Rock. John? Yes. So updates. We are currently in '20, and '20 at this moment is still in beta. But by the time you get this podcast, it'll probably be out, and we highly recommend that you go to that. Again, minor releases are just bug fixes. So you'll want those bug fixes, and you want to get to that. On the major front, we can finally talk about 19. Wow. Yeah. So we've done a lot of work to get 19. And again, going back to our release framework, our new one, we're trying to get two major versions out a year. And so we're hoping to get this one out pretty soon to alpha testing within probably the next month and a half. That's exciting. Yeah. Now, testing does take some time. So by the time, if you're just thinking about it from a general release perspective, you still will see some time. But from an internal perspective, it's starting to feel the boat is coming into the harbor. And so if you want a little bit internal perspective of how we see it, we're putting the minor touches on some things. It's really interesting because we're really project managing the critical path. Through the whole version 19, we've known what a critical path is, what's the one line of code that we need to write, that we need to really, really project manage to a T. And then everything else is assembled around that. So we're in that time of the project where the critical path is getting a light at the end of the tunnel. And so some features that we had internally planned for 'nineteen are getting pushed to 'twenty. And some of those features were supposed to be in 'seventeen and 'eighteen. They're just not that major. And so they just kind of live in this perpetual push ahead. That makes sense. Well, this is very exciting because this is the initiation of really the new process of major versions. And there's always a lot of adjustments upfront when a process this has changed, but we're really excited about it. And if people in the community are thinking, why do they keep talking about the version so far ahead? Why, , well, '19 wraps up for us at about this time, and then we are on thinking about '20. So we are thinking at a different pace than what is actually being delivered or revealed. Yeah. And I think that's the interesting part is by the time a version's released, it's old news to us. We're , Oh, really? Oh yeah, that version. Internally, we're at that stage where we're getting close. And the features that we have in '19 are really exciting with the new connection board. And that's not really the connection board, we call it the connection list. And it's really exciting. And so the team has been putting a lot of thought and engineering into how do we get this list performing super well. We've had lots of meetings on that. And the cool thing is it's not really a traditional performance problem for us, which is usually how do we get the data down to the client? That part's actually really fast. It's now, how do we get the JavaScript, the reactive JavaScript to not lock up the UI thread? So there's just so much virtualization that's happening on the client to get this whole thing performing. So it's a different type of engineering problem. Lot of innovation happening to make that come to be. Yeah. And it's working, so it's just difficult. That's great. Well, we've got to move on to our next topic, John. It is the hot topic right now, and that is vibe coding. Now, our conversation here today has some inspiration from the AI Daily Brief podcast with Nathaniel Whitmore, but let's get straight to the point. Vibe coding's everywhere, and it kind of begs this question, is software dead? And so that's what we're gonna talk about today. There's a attention around that. There's a lot to understand, a lot of curiosity. Right now, the the current narrative is saying that AI can build apps immediately. People are recreating SaaS tools in hours, and markets are panicking about software dying. That's kinda the lay of the land right now. If we reframe this, though, for churches, the real question is not is software dead. The real question churches should be asking themselves is whether they should stop buying platforms and just vibe code everything. Well, what we're going to talk about here today is no software isn't dead. Systems still do matter, and systems can't just be vibed. So before we jump into all the meat of this, John, can you define what vibe coding actually is? Yeah. So vibe coding is a term that was created recently from Andrew Kapathi, and he came up with this concept of, Hey, I'm using AI to help me in my coding, and it's actually doing a majority of the coding, and I'm not putting a lot of time and effort into it. I'm just thinking and just saying what I want and seeing what comes out. And it gets better and So it's really little to no upfront effort. It's rapid innovation, rapid iteration, trying to get it to do what you want, and when it's not quite you, give it a little bit more feedback and it changes. It's really experimentation over planning. So you're just vibing. That's where the term comes from. It's almost you're in a hypnotic state or a drug induced state. And it's really about speed, speed over structure. Now, it can feel pretty magical. There's been some people recently, someone at the, I think it was the New York Times said they wanted to dispute the fact that this is a thing. They they tried to create a monday.com clone, and they shocked themselves in the fact that it actually was pretty much monday.com, at least for what they needed. So there's a low barrier to entry, at least a perceived low barrier to entry. There's fast feedback. You get to immediate, within minutes, sometimes even a few hours, you can have fast feedback and you see very tangible, visible progress. And so there's a lot of use cases where this could be a thing already. For small internal tools, ministry specific little helpers, excuse me, small dashboards, reports, and some administrative conveniences. I feel that's a good use for that. But as we go into, is this a good idea, or what is the future of this? I think the first thing I'd probably want to say is anybody who talks with certainty about where AI is going is probably the one person you shouldn't listen to. The only wrong answer is the one said uncertainty, because we just don't know. And what is possible today, or maybe impossible today, might be possible later. It's just a fast moving argument. In fact, this morning, Elon tweeted that learning a programming language is not needed because within months, computers, people vibe coding would actually be the the the AI will actually not be writing computer languages. It'll be writing machine code. So just literally assembly or binary, ones and zeros. Wow. Now he's getting a lot of pushback from that. And I think rightfully so. And we'll talk a little bit about why later in this section, but it just goes to show you, everybody's saying these big terms or big thoughts. And I think it's actually good that we do this because it helps us get to the right thought. Throughout my whole career, everything in technology has been one thing, is a pendulum. It swings back and forth, radically going too far and then radically swifting back the other way. For instance, the big thing in technology for decades has been, should the applications run on the server or on the client? And it used to be all server, that was mainframe. Then it went all client server. A majority, a vast majority was on the client. Then it went to the web, where it's a little of both, but it never really came into the middle, it just swings rapidly back and forth. I think we're going to see the same type of thing with this technology. But I think another thing that we have to be really clear about is when we're coding as programmers, very little of our time is actually spent top of mind writing code. That's not an activity that we spend a lot of time on. We do program, but that's not the majority of what our time at Spark or Rock or any development company is spent on. That's a really good misconception that you're addressing there. What is it that we're spending our time on? Well, really thinking about systems and how the system should work, how it should and how it should not work. So I would say that the system takes 95% of our time and thoughts. The 5% of coding is not as important and is easy. I think even our developers would say that's the easy part. So, I think again, right now there's some good use cases for this. We actually want people to do that. But it's not necessarily a replacement for systems. I don't think you Right now, there is no Vibe system coding. And I actually think that those two terms would be in conflict with each other. Oh, that's interesting. Because vibe means I'm top of mind stream of thought, and you can't build systems off top of mind stream of thought. It has to be You have to think through where are you going. It's kind of the Wayne Gretzky quote, Don't skate to where the puck is, skate to where the puck is going. Well, that means you have to think about where that is. Now, is it possible that in the future AI can help us with that? Probably. I don't know. Probably. But I think it's going to be much more of a Either it's going to have to infer that or it's going to have to interview for that. And I would go back to what is the importance of a computer science degree? One, I think it can get you further faster in the beginning. I know a lot of people who don't have a degree who are amazing, but they had to get their reps in and experience hands on. But I use very little of the coding practices that I learned in college, because those programming languages are dead. What I use every day too is understanding how to create databases, third normal form, and thinking about what the data structure needs to do for today, but also how it needs to be extensible for possibly something in the future. And I think that's, again, what a lot of the development resources are put onto. So if we think about the vibe coding, vibe coding is the feature. Systems are what the features sit on top of. And so the reporter who did the monday.com thing, she only created the features that she used that day. And what percent of features do the average users actually use? It's probably 5% of what any product does. So she created those things. But to create a robust system that can do all those things is way more difficult. Now, could that be Vibe coded? Maybe. Maybe with someone who had a systems knowledge, was also thinking about, and then this needs to be put into a system, perhaps. So features are things that we see, interfaces and views, views of the product. But the system is more than that. It's the data model that supports the data today, but also in the future. It's foundational type utilities workflows. Now, when I say workflow, you probably think Rock workflow, that's kind of it, but even deeper, how does data flow through the system and get automated through the system? Permissions, the biggest problem right now, today, with AI is security. If you watch the Cloudbot, that's a security disaster. Think it's actually a good thing, because we're learning on a very small sandbox. Things audit trails are part of the systems, lifecycle ownership. A lot of the things that we think about is how do we transition things and build things that will work in the future? And so it's very anti vibe. In fact, if most people could sit in some of the meetings we have, they would be bored to death. Because we're worrying about things in the future. How's that going to play in the future? All the things that you have to. So you can vibe features, but today you cannot vibe systems. That's a good clarification. Yeah. Now, again, we don't know in the future, maybe that's a thing. Low effort creation produces features. Systems require forethought constraints in engineering. A good example of that is the business logic within Rock. So for instance, every time you save a person, no matter where you are in Rock, we call a single place that says, Save this person for me. When that person is saved, two things happen. There's a, what we call pre change, pre save logic. So the pre save logic goes through and goes, Okay, I'm going to look at what you want me to save. Oh, no, there's a business rule here that you're breaking. This is a required field, you have to give it to me. Or connection status can't be, or deceased There's pre save changes, and then there's post save changes. And so that post save changes are , Okay, what you gave me is fine, I saved it. I'm going to hand it back to you because you need to get back to whatever you're doing, but I got to go do some other stuff. So for instance, if you save a person, did you create a family? Probably not. Did you create a known relationship group? Probably not. All those other things happen behind the scenes. Now think about that, if you're vibe coding, how would to do that? Yep. Also, if you're vibe coding, you don't want to do that every time you save a person. You don't want to put that all over the place. You want to put that in one central place. So, hey, every time you save a person, you have to do this. Now, could you speak that into the vibe coding requirements? Sure, you could, but you have to know to do that. Yep. You have to understand the system's thinking behind that. So these systems take a lot of effort and forethought. And that's, again, I think if you look at our team, that's what our team does. So defining in systems, what's authoritative? What is the authoritative source of that data? Modeling, again, data that had been around for a while, but also will live for longer. So how do we understand how we're going to shift this data and how is this data going to work from the past and in the future? Deciding what to do when things go wrong. Every system's going to have what we call exceptions. And so what happens when an exception happens? Definitely planning for change over time. A lot of what we do, we wrestle with, Okay, well, how's that going to work in the future if we want to do this? I think the best developers are those who have a concept of the future and who have empathy for themselves in the future and the individuals using the product. We're not typing as much code as people think. We do type a lot of code. Let's be clear. But that's not what the hard part is. Even when we're typing code, it's more about, Okay, how do I write this code in a way that's easily to be maintained, that's easily to be understood? Now you could say in the future, well, AI won't have to know those things. That's a developer saying, I don't need to write comments, my code is the comments. That's a Although terrible way to I have had people tell me that straight up. Engineering is the work of deciding what you can't or shouldn't do, just as much as what you can and should do. Oh, wow. So it sounds the bottom line here is that for churches, right? If we circle back to the reality of vibe coding in churches, having a system of record isn't an option. And and we should be looking at all of these choices and all of this through the lens of what is the reality in ministry. So for example, things you should probably not vibe code sound they might be kids check-in and security. There's so much underlying those features that if something were to be left out in business logic, you could have a lot of fail points and those could be fairly catastrophic. Yeah, I mean, think about group requirements. That's a very system feature. That's not a vibe codable. You would not wanna vibe code that because this person else in their background check expires. Well, what does that mean to the check-in system? What does that mean to volunteer check-in. What does that mean to a host of things? It's an infrastructure piece. That's true. And similar with tracking contributions and the statements that are there, especially with a platform Rock that's so open and can have so many input areas. Care notes and confidentiality, that's where we're It makes a big difference how we're handling the people that we're caring for. As you mentioned, background checks, probably anything having to do with volunteer eligibility. There are a lot of security potential concerns around that. And then attendance, engagement history, some of those things where we're also surfacing data to people, we just can't afford to have that go wrong. , we're really not looking at e commerce, we're talking about churches, right? So we're not talking about side projects. Those are a great use of vibe coding. But we're looking at areas where our members and attendees provide us with trust, where we're talking about security, where we're dealing with stewardship. It sounds really if it's something that touches kids, money or care, you shouldn't vibe it. Yeah. And I think that's a good point to to pause and say, this can all sound very protectionist, right? Oh, you're developers. Of course you want to protect your job from AI. And it's quite the opposite. We're using AI more and more and more, and we want everyone to use AI more and more and more. So we want churches to vibe code. It's just you said, what do you vibe code? And having a healthy understanding of boundaries of when something should be vibe coded and when something probably should not be vibe coded. Honestly, it's probably one of the most exciting times in technology, especially church technology in the last twenty years. We're kids in candy stores. Yes. And I think many people are. And just as we bring caution about how we use AI in pastorial areas, why do we do that? Well, first of all, there's a spirituality to that. But second of all, this is a serious area, you just can't just vibe pastor your way And through that's one thing I think is a good tool, it's easy to see how AI can impact someone else's area, because we don't really understand it, but it's often different when it's applied to ours. Then we're , Okay, but we have certain concerns that we have to mitigate. , what if we just made, let's vibe care for our care ministries. Well, I think if you're in the care ministries, you could probably list 10 things that I don't even understand that have to be considered beyond just the spirituality perspective. So again, we want this, and we're actually trying to figure out how do we enable vibe coding within Rock? Now, don't think that we have the answer to that. We are wrestling with that ourselves. We're actually thinking through how do we show the intent to AI to say, Okay, if you're going to vibe code for Rock, here's how that could happen. And we don't have the answer to that. Well, that's pretty fascinating. But it all starts with thinking about it. Absolutely. And you also talked about the system of record, and that's super important, especially for major systems a CRM or ERP, which is what Rock is to churches. There has to be a single source of truth. We have to have structured data. You can't just keep data in five places. We have to have defined workflows, permissions are important. Without that, and the audibility and accountability, without that, AI is just guessing. You haven't described to it what you want in all those areas, so therefore it must infer that. And it's not it's too dumb to know, it's just , Well, you tell it. And it would be difficult to come up with a complete list of all the things that you would have to tell it in a one off project. Almost impossible. And I think Justin Huang, CEO of NVIDIA, said it pretty clearly a week or two ago. He said, Hey, systems are important. Let's just say we had this advanced robotic AI robot who could go around and do anything. Would it create the screwdriver or would it just use the screwdriver? And so what he's saying is, would these AIs who are creating software, are they just gonna create this, recreate the system, or are they going to use the systems that are already there and improve the systems that are already there? And I think, again, that's not so much on the extreme. I think that's a blending. And I think reality usually is in the middle. And I think it's going to be something more that, where we are going to have these systems, , take Salesforce, it's a good CRM, why wouldn't AI extend Salesforce? And if there's a new Salesforce that's all AI driven, I think it's going to be created by software engineers who are using AI and using the experiences and the knowledge that they have to bring these things about versus someone just saying, Hey, go make me a Salesforce clone. Sure. You'll get a UI that looks a Salesforce, but you're not going to get the systems part of that. And I think that's another point too. When you think about AI, it's a magic, but if you boil it down to it's a distilled version machine that has all of human knowledge inside of it. And it can synthesize from that and it can mix from that. But what it can't do is it can't create novel ideas. That's something our Creator gave to us. That's what the technologists still don't understand because they don't have a biblical worldview. It can look novel thinking, but it's not novel thinking. It's a rapid mixing at scale of former ideas that humans had. And if you want to prove that to yourself, go read in detail how Einstein created the theory of relativity. If you think, if you read about the thought experiences that he did to come up with those concepts, you'll realize that that is a gift from God. That was not a mixing of previous thoughts. It's actually insane how he did it. I was doing a presentation on this for some students at one of the local colleges, and I was reading about that, I was just blown away by that. So AI can recombine these patterns. It can accelerate known paths. Again, the New York Times example is a great one. Make me a monday.com. Oh, okay. Well, we have these concepts. But if you look at monday.com, it has some pretty unique user experience concepts in that product, that a lot of products, including ours, are inspired by. But who's going to come up with those novel concepts? Wisdom still lives within people, and that means that the accountability still needs to live with us too. So AI is a multiplier, but it's not a moral compass, and it's not a novel innovator. Great point. And I think we've all seen areas just in basic use of AI, where AI tells us the wrong thing. And it's just fairly confident about that. You don't want to hand your moral compass over to that. Yeah, and I think if you think about vibe coding, and again, this is vibe coding today, of course it's going to get better. But you might be familiar, this is a very common thing or analogy within the church space. So in your children's ministry, it might be the concept of the label ball. So many children's ministries will take the labels off kids and they start making a ball out of it, and the ball gets bigger and bigger and bigger, and some of them have some pretty amazing label balls. That's kind of what vibe coding is. It's taking an idea and making a little teeny tiny ball, and it's not quite right, so then you give it some more stuff. It starts by coming at it all these different directions, you build up this huge label ball. Well, if you're trying to make a ball, that's not the most efficient, effective, and it's not really a great ball when you're done. I mean, it's not a basketball. That's right. Today, that's kind of what vibe coding is. Will it get better? Yeah, but I think again, the vibe has to drop off because you can't vibe systems. Even with the most self aware AI, you can't do that. It's got to ask you questions. It's got to make sure you understand your full describe what Rock does in four paragraphs. You'd have to give it volumes. And I also want a workflow engine, and the workflow engine should work this, and it should have these features, and you should have field types. Field types should be Here's the I forget how many field types, we have way too many field types, hundreds of field types. I need a field type that's a group and a role picker. Also the business logic is you can't pick this role if And it's not in the the data structure and they're just, it would be Yeah, try to explain the attribute system. Oh my goodness. I'm not even sure we could do that. There's just so many edge cases. So at the end of the day, with the analogy of the label ball, we don't end up with a system, we end up with a pile of ideas. Think going back to when should AI be applied is it seems easy to those who don't have the domain knowledge, I should say. Think about it this way. It's always good to switch the use case for an analogy. There's no question that AI can help in our medical fields. I mean, does. We've all probably asked AI a question about some medical condition that we might have. So does that mean that we would just go to our next door neighbor and say, Hey, I don't need my doctor anymore. , Vibe, heal me. I won't be the first to try that, I can tell you. Yeah. So it seems crazy about that. Yes. But it's, in some ways, kind of the same thing. Now, that mean that that person should never use AI to do some health, or maybe put together an exercise plan, or put together a food diet? Of course they should. And that's where I guess we're saying too, that's the good use of vibe coding, especially today. But I'd prefer the doctor to use AI in conjunction with his knowledge and skills to heal me versus my next door neighbor, especially if it comes down to surgery. That'd be a very bad thing. So again, if we look back to that, I think, and what we want to try to do is make Rock the backplane and AI as a new option as an interface. So again, you can vibe features off of that system, but you shouldn't vibe the system itself. Now, AI can helpful in creating of the system, but you're not gonna vibe it. You do not want a vibe to the system. Imagine if we vibed the system. Yeah, we certainly wouldn't be where we are today. And you'd reach a limit on extensibility. Even if you managed to cobble something together that worked, it probably couldn't have the flexibility needed for everyone that uses it today. And at some point you just can't extend it anymore. You just have to start over. Yeah. And it kind of goes back to some of the concepts I was talking about at the conference. While we're vibing interfaces and we're vibing software that exists today, I believe that the software that exists today is antiquated and will not be existing in the future. The interface is going to be the agent itself. So the fact that there's a RockRMS admin portal that you go into, and you go over here to add a group, you go over here to do That's gone in a decade or two. A lot of it's just going to happen without us even being involved. That's why these agent skills are so important. Because initially when we roll out these agent skills, you're going to be using them in a chat interface. In the future, it's just going to be making those changes for you. You're not going to need an interface. Most of the things are not going to be triggered from an interface. It's going be , Oh, Ted came to the website. Oh, that's interesting. I'm going to go update this. I'm going to go update that. Oh, he was looking at marriage counseling. Oh, that's interesting. I might put a connection request in so that a human pastor can go have a casual conversation. Those are the types of things that are going to happen. We're going to spend less and less of our time behind interfaces and more and more of our time not actually interfacing with the computer, just getting little trigger alerts of just the small pieces of what we do today. Because the majority of the work we do is going to be automated. Fascinating. And I hope so, because a lot of the stuff I do a lot is not that fun. I'll be able to do more of the fun stuff. Another story just came out yesterday that said that productive AI users today actually work harder and more than less. That was sort of the opposite of what everyone inferred at the time. But it kind of goes back to when computers were first coming out or when cell phones were first coming out and all sorts of new technology and everyone predicted, Oh, this is the end of long, hard work. And that's not the case. It's different work. Yeah. Now they're also insanely more productive. Yes. So it's not they're putting more effort in and getting the same results. No, they're insanely more productive. One example, which I thought was interesting, was , Okay, well that's interesting, but how's that true? And they were saying how many productive AI users today, before they go to lunch, they'll type a heavy prompt into the AI and then hit enter while they go eat lunch. And so it's still working back And who hasn't done that? Right before I go to a meeting, I'm going to type in this prompt and hit enter so that I don't have to watch it think. And we've all done that. In fact, you've probably done that four times, you go to a meeting, you're , Okay, I got this one to go do this one, I'll go get that one to go do this one. And then when you come back, you're , Oh, that's great. And occasionally that's, Oh, that was way off track. It went and did a bunch of stuff it didn't need to. But at least you didn't have to sit there and watch Yeah. Although I do have compassion. I have compassion for machines. I think I've said that a few times. And so I think about all the energy I just wasted and machine time I stole for that stupid thing or something I wasn't clear about. So anyways, I guess to wrap it all up, software today is not dead. Vibe coding is a great thing, but understand what you're vibe coding. Are you vibe coding an interface and a feature, are you vibe coding a system? And systems are much different. And I think they look easy on the surface, because all we can see is the interface. But the business logic and the systems thinking behind it is way deeper than I think most people understand. And it's the same thing with any platform. Dan Heath has that podcast, I highly recommend it, where he talks about everybody's profession. And it's amazing how deep the professions go, even the dog grooming one. How much detail could there be in dog grooming? Oh, there's a lot. There's a lot of detail. And it's the same thing in I think in any industry. Very true. Thanks for sharing those thoughts. That's a great perspective that ties in how churches should be thinking about the subject of vibe coding. AI Daily Brief. Everybody, if you're interested in AI, Nathaniel, who runs that, super great thinker. He synthesizes so many ideas from others and kind of boils it down into thought. And he takes away a lot of the extremes for you. He's , Hey, I think that's an extremist And he brings it, I feel he, it's good summary, but I enjoy his thinking and his commentary on AI more than anything. That's great. Alright. Let's pivot to a different topic, and that is the topic of early access. So this is a very Rock Community specific topic. It's come up a few times recently in different contexts, so we wanted to take a little bit of time here in our podcast just to revisit this. The basic foundation of Rock, which as our listening audience here, that Rock powers churches and churches power rocks. So it's this reciprocal ecosystem that we're all a part of. And success is the shared responsibility of everyone who's involved. We believe that so much, we put our funding model on top of that. that is maybe the biggest commitment that you can make. Huge. Yes. And it's not too different from your funding model as a church. You are creating value, pastoral value, spiritual assistance and growth help and pastoring to church members. And they are helping to fund this ministry in reaching other people and reaching your communities and helping people grow. And so it's very similar to the same difficult model that that we know that churches have adopted as well. So the conversation here, , in this podcast is specifically about that responsibility and stewardship that we share to protect what's possible with Rock. So, , but quick revisit the the donation model for Rock is that Rock is, don't forget, an open software for for churches to use. And Spark, who owns all of the intellectual property of Rock, is a nonprofit that's driven by a board. So we do not charge licensing fees. We could legitimately do that, but we've elected not to. And we operate instead with a suggested donation model. That means that we've done the calculations to understand the systemic responsibility for everyone that's using Rock. If everyone contributes a little of what they have in different areas in the right ways, then that's what keeps Rock running. So our whole model is based on that. Our donation rate for 2026 is $4.45 per average attendee per year. And that's based on the number that your pastor would mention if he's talking about his church, it's your average weekly attendees and it includes adults and children. And again, it's just the number your pastor would share. This model lets churches of all sizes use enterprise level technology because one of our core values is accessibility. And we want the best technology to be accessible to churches regardless of their size or maybe their newness. We don't have forced contracts. We don't have, , for the free, you get this little bit, then we're going to have a paywall to get anything of real value. And so that is a very generosity based model. Now, we also understand that some churches are unable to donate, and this is legitimate. So we've created a grant concept that allows churches or nonprofits that are very small, very new, or going through a very serious hardship to still be able to use Rock just everyone else despite those circumstances. So we have a step down grant program, and that allows a church to request a difference on their donation, we're happy to support that. We've never turned a church down when it comes to a grant. Now, though, we've heard a couple of concerning things from some vendors that are kind of Rock community aligned. We just kind of wanted to talk through those. One comment that we heard recently was about a vendor having sympathy for churches that are not in early access. Early access again is the access given to churches that are donating at the appropriate level or have a grant for that. And they have immediate access to all the features that come out in Rock, there is a one year deferral for those that are not donating. And there are a lot of great reasons for that. One is the most engaged people in the community are working through things, and they're able to help provide that support inside our community structures before those who might be less engaged are involved. But essentially, it also kind of rewards the behavior that keeps Rock sustainable. And so when we hear a vendor say that they have sympathy for churches that are not in early access, that gives us pause. Yeah, it's almost the analogy I would say is, I have sympathy for this person who's hungry, but they're sitting right outside the food bank. If you're sitting in that situation, you're not getting the newest features, you're not getting all the bug fixes. So you really are starving of this technology. And the answer is right behind you. You don't have to be in that state, there's a grant program. So in our minds, it's , Oh no, there's misunderstanding that there's a grant program. That's exactly right. We want everybody to be on the latest and have accessibility to the latest. Yes. And at Spark, we have sympathy for churches too. That's why we created that grant process. We have sympathy for small churches, for new ministries, for churches that face real hardship. We understand that those are realities some churches churches are dealing with, and we don't want them to sit outside the food bank without food. Yeah. Tension arises though when churches that are fully capable of donating intentionally choose not to participate. And then to frame that as sympathy, it just doesn't sit well. And that's a very small number, it does It's , Oh, I can save money and use this for free by just running an old version. Right. And that's not the intent. That's not the intent in a reciprocity kind of ecosystem. Yeah, that's someone who's taking from the community, not necessarily from us, but they're taking from the community not giving back. So there's a distinction that we want to call out between being unable to give and choosing not to. And we have high sympathy those who can't. That's exactly true. It's not church size things. Sometimes there's been a big church who's going through a legal battle or maybe their senior pastor just left and we get it. We've been in all those situations. We understand that. And I love it when they do come. Even some of the smaller ones, they come so humble, Hey, we really want to use it. We can't really give much, but we can give this much. Can we And it's , yes. It's actually a celebration when that happens. It's It is. We're joining the churches in the community in their celebrations and in their sufferings. And we feel that's an essential part of this community. There's one other thing that we've heard in the community that we would just want to mention. Another vendor has actually encouraged some large churches to spend millions on technology upgrades and donate nothing to Spark at the same time. They cut their donation, wasn't it? Yes. They were donating to say, hey, well, you can cut the donation and then spend more money with us to buy Wi Fi gear. They had a commitment to donate and they said, just don't do it. So the way that they were basically funding their own product and service sales was by saying, Oh, that spark donation is optional. And while, of course, a donation is optional, that is completely not the right way to look at that. So it does raise a concern because Rock is actually the foundation of their technical ecosystem. And now it's being starved. If a church is willing to invest in infrastructure, in all sorts of technology and trainings and services, and not willing to invest in the foundation of their whole system, what their ministries used to rely on, that is actually maybe a shortsighted perspective. Rock doesn't work unless it's funded. And again, if a church is smaller in a hardship, this is when you want to apply for a grant and we will have nothing but empathy for your situation and we'll be happy to work with you. And I think there might be a thought that says, well, you made a system and now people are using the system to achieve or maximize their goals or their desires or their wants. What I would probably say is we made a system intentionally not made on market norms Because we didn't want to play in the market norms. And I think we see a lot of people, including ourselves, upset at people who come in to serve churches with market norms and gouge and under innovate. And so we were intentional from the very beginning. We didn't want to play by market norms. And so can you game our system on market norms? Yes. But that's not why we did this. If we were playing out in the corporate world, I'd be , Good for doing Dog's gonna be a dog, you're doing it, but this isn't why we do it. No, it's not. And it's possibly misunderstood sometimes. So it's good to, , have a reminder and a discussion about that. But, , I would just be cautious of any vendor that says, , spend a lot of money with us and make sure your spark donation is optional. They might be missing the fundamental reason in existence of how we work. And we have had people say, Well, don't you just go back to the market norm and just do it that way? It's , I mean, we hear it all the time. That's the recommendation if an issue this comes up. And it's , well, we prefer not to, and we don't feel we were called to. Yep. So here's what I would say. If your church is really small or you're experiencing a hardship, please apply for a grant. That's the purpose of the grant process, and we're happy to talk about that with you. If your church is healthy and benefiting from the use of Rock, please participate responsibly. That's how it works. And if your organization builds on Rock, help us encourage that sustainability rather than avoidance. Join us in the goal to have a fully funded, healthy operational spark for long term. Don't forget, as we talked about really early in this podcast, even spark is working so hard to put out major features, updates and innovations every year. We're working to stay, , cutting edge with AI and ministry and how those things come together. If you really wanted an unfunded spark, then you would be experiencing something that's really stagnant, which we know is not what the community wants and is not what we want. So the healthy innovation and growth here absolutely has to have a funding basis. The donation model was built for accessibility. It was built for shared ownership. We truly do believe everything is better together inside the Rock community, but it wasn't built to subsidize capable organizations that make a choice about that participation. Let's tie it all back again. Rock powers churches, churches power Rock, and the future depends on both sides prioritizing that relationship for best health. Again, we know this is something that really only impacts a few churches and likely none of our listening audience. But we just want to share with you that those perspectives, the more you can understand them and help share the reality of that with the other churches that you interact with, the more healthy and successful Rock will continue to be. So we thank you for that. Now, a couple of fun points. Rx twenty six is coming. I know we just had a conference, but it is always coming for the next one. And our team had a chance to tour our site yesterday, which was great to envision all the spaces and all the activities that will happen. We are so excited for our next major community event. Registration is open now at early bird ticket prices, so you'll want to get those locked in. They will go up to a standard rate here probably in the next month or so. So go ahead and get that approval and get that in. And I also want to mention that the main hotel that we'll be having probably after hours events in is about 30% full. So I know it sounds we're really early. It's February. That's coming up in November, but we are not. And you definitely don't want to lose out on the opportunity to stay at that hotel, which you can find a link for directly on our Rx twenty six website. You might also know if you've been on our website, the Rock website has been totally refreshed, so we encourage you to check it out and share it with the churches in your network that may have been thinking about Rock but might have that misconception that Rock requires a developer. We've updated our website to help truly understand how churches that might need an essentials perspective can approach a move to Rock Now. And so there's a lot of great content and information there. We've talked a lot about what essentials means, I think in our most recent podcast before this one, and there will continue to be a lot of great information coming out about that. But help us spread the word that Rock does not require a full technical team. Rock just requires a little bit of elbow grease and great engagement with the community. Alright. Thank you so much for joining us again for another Rockcast. Be sure to subscribe wherever you get your podcasts so you don't miss our next update. And we will have much more to share with you the next time.