Hey, Luke, I got a problem. Tell me about it. There are so many things that are changing in our technological landscape when it comes to software. It's never been more difficult to know whether or not custom software is the solution for a ministry where they're going to hire a company to go down that path of building them exactly the thing they need. and likely spend a fair amount of money doing that, or there's an off-the-shelf solution.

And what's even interesting about that is that there are more off-the-shelf solutions in niche industries than there's ever been. But that's going to be probably cheaper than a custom. I don't know how to think about this and I'm pretty sure it's only going to get worse. What do we do?

Yep. It is a huge, like multivariate problem that is, that's a question that so many ministries and organizations are asking right across the board. And I have two friends that I think would be really the right people to talk to. One is Cameron, and he's a developer.

He's a solution designer. He's got a lot of experience in the creation of software and finding solutions. And the other is Jonathan. He has also a deep background in technology and business and entrepreneurship, but also in ministry.

So I think if we talk to them, we might have a better picture to put together. Let's have a chat. Let's do it. Welcome to the Blue Vineyard podcast where we explore the Adventist digital ecosystem.

My name is Luke Farooja, I'm the co-founder of Blue Vineyard and I'll be your host. In each episode we will sit down with different leaders from the ministry and technology worlds to see their insights, hear inspiring stories and get their hard-earned wisdom for future ministry leaders to use. Hey, we're gonna ask a very interesting question of two very intelligent people who know more about the topic of How do you know? when to choose custom software build to build out custom software or to choose something that is off the shelf for your ministry use case and I have two incredible individuals that I am excited to debate this interesting topic. I know a lot of ministries, they don't have a good idea of when to do what and maybe they're preconceived ideas about how these different things, how much they cost and how much they don't cost and when to do what.

And a lot of times we're just having our head down and doing the work. So I'm going to start off this conversation. Cameron, quick, tell me just a little bit of context for why you're going to answer this question the way that you're going to answer it. So I'll just give you a quick time to give you some context.

When should a ministry choose whether or not to use custom software or software off the shelf for their ministry? The answer I think lies in how much time and how much of a critical component it is. So how much time do they spend in it? every day, every week, and how critical is it for them. If it's a website running something standard like WordPress is probably the right answer because they're probably not spending hours every day in it, but if they're running a CRM contact donor management piece of software it probably needs to be something if they're spending hours in the day and it's a core component of their ministry It's probably something that needs to be custom that is refined and honed down to meeting their needs for where they're spending a lot of their time.

Would you also say, Cameron, I'm just curious, if you are, where would the consideration of costs come into that? It comes probably down to how much ministry has going through from a finance perspective. If they're only a little tiny ministry, you probably want to, they're probably not spending a lot of time in it. If they're a larger ministry and they find that they're spending a decent amount of time in it, they have a lot of donors and their time is tied up very much either responding to donors or providing receipts and statements and communicating with the donors.

Then they probably want something that's a bit more custom and refined to what they're using. rather than just something that's existing on the shelf that they're going to have to spend more time modifying. I've seen a couple of cases where they've used something that's off the shelf and they end up spending multiple times updating the same piece of information across multiple systems to keep everything in sync with the latest information and that just slows down the day. and introduces the chance for errors to happen. All right, yeah. No, that's a good point.

Jonathan, I'd throw the same question back to you. Kind of give me a little bit of context for how you would answer this question, this larger question that we're going to narrow in during the course of this interview, this debate. How do you think about choosing custom software that going that route? versus something that is off the shelf, you know, especially when we're dealing with ministries. Yeah.

I like the question. It's important, as you opened up with, it's an important piece of the puzzle. There's a lot of things in a ministry that generally, if you're in ministry, you didn't start out with this. We really want to make, we want to spend our time making decisions about software.

There are some exceptions, of course, if software is your ministry. When I think about this decision of do you take something off the shelf or invest in building, there are three factors that weigh in my mind. I think it's worth saying to the listeners, you get the joy of we've not actually compared any notes on this. It'd be interesting to see where this goes.

For me, there's three things. I'll call them the three Cs. The first is core. It's this idea of how closely aligned is the software to the core of what you are doing as an organization.

As Cameron just made reference to, if it's something about donor management or a donor-based system, and that's really a big piece of your organization, then whichever direction you go, whether customer or off the shelf, I think should have a lot more weight. If you are making a decision about a piece of software that's pretty adjacent, like off to the side, then to me, what you choose to do there, it's less important, right? So the core is one of the factors to be weighing. The other is the cost and cost through a number of different lenses.

There is the cost to buy versus build. There's the cost to maintain. There's also the opportunity cost, right? Like the time that it's going to take you to, if you're choosing to build custom, for instance, to scope and to really clarify to and the things that you're not going to be able to do because you were investing in that versus something off the shelf.

And the third factor that I think about is what I'm going to call it confidence. There is if you're choosing to purchase an off the shelf solution, there is your confidence in the organization providing that like how long have they been doing this? What's what is their alignment with what your goals are as an organization? right? And how critical is that alignment that goes back to the core and the cost, right?

Like, if it's really close to your if it's pretty close to your core, and we're talking about a high cost, you need to have a really high confidence in if it's an external organization that you're that you're looking at here. And then the other piece of that you can look at confidence through a few different lenses. The other piece of that is your own internal team. Like one of the things I love that Cameron made reference to If someone is having to enter data in one system and then into another and another, not only is it prone to error, but that's a poor user experience.

Whether it's off the shelf or custom, the intended users need to have confidence in the solution itself and those backing the solution. If it's an off the shelf and you feel a lot of confidence in the company, that can be great versus a lack of confidence in the internal resources that you'd have to both build. and maintain software. If it came down to a dependency on one person internally, then there's a risk of having much lower confidence about that. Those are the three things that I think about.

How aligned is the need that you're trying to solve with your core as an organization, what you do missionally? What are the actual costs? It's not as simple as just a price tag or an initial build. And then what is your confidence in one direction or another, as you're weighing the factors at play?

Interesting. So I would be curious from an opening perspective from both of your sides. I think both of you have touched on this topic, but I'd like to put a finer point on it. Cameron, would you be able to start by telling us the... the greatest risks that you see for people using off the shelf solutions versus, um, custom built.

So the on the shelf, off the shelf stuff, you run into the issue of it not actually fitting exactly what you do. So much in ministry is just slightly unique. A lot of the time it's not built for ministry. I remember I was working at a conference and they were looking at integrating Xero, the accounting software in, and they ended up not doing it because it was just so much extra work to get it to fit with the uniqueness of the church environment.

They were having to do things where they were duplicating. Someone make a donation. They then had to go and create an invoice and they would people sometimes want to make an anonymous donation. And you start running into all these situations where normal accounting software just doesn't suit that.

Some of the categorizations were just really challenging. They kind of worked for super large churches, but they had to have someone who was pretty much dedicated to that role. And I think that's one of the interesting components. With that sort of thing is there's a lot of complexities that are very different from normal business Yeah with ministry And I've seen on the shelf work in some situations, but they ended up having to have someone there doing a lot of extra heavy lifting I've helped out road to Bethlehem in Victoria with some CRM set up for capturing information and that sort of thing for people who were coming to their event and it worked but there was a bunch of stuff that they wanted to do with volunteers they needed to do validating working with children checks and making sure they were up to date and there wasn't a way to do that without someone manually going in taking each number checking that number against the database with the government to make sure that they're eligible.

And if there was an automated system, it would have been a 15 minute job, probably not even 15 minutes, it would have been automated. But they ended up having to spend days waiting through the list of a couple of hundred people just to find out, oh, everyone is eligible to volunteer and help. So, yeah. Cameron, I have a quick, I have a question, something that would help frame this a bit for me.

You mentioned the uniqueness, and that checks out my own experience. How confident do you feel that the uniqueness from one ministry to the next is justified? Because I'm tracking the logic, but versus adopting to a more standard business practice. I can very much envision, the anonymous donor I think is a great example of something that businesses don't typically have anonymous customers.

That's a great example, but that one aside, For instance, I can imagine a ministry just walk in and say, well, we're very unique and we have all these unique ways of doing things. And my, my more of my mind first goes like, well, is that justified though? Like of the 10 things that you do uniquely, do you need to do all 10 of those uniquely or is two of them like really make sense? And the rest you should probably just get with the times.

No, no, no pun intended. Yeah, no, that is a problem with ministries. a lot of the time I think it's because they have less exposure to the business world. Yeah. And that is something that I've done before is I've been like, Hey guys, are you sure this is the right way to do this?

Like, can we standardize and simplify how you're doing it? I think that's part of the process with a custom piece of software is to come back to them and say, well, you you've got these 10 things that you're doing that are unique, you really only need two of them to be unique. I could see a real nightmare where if you were to scope out all the unique things for a ministry, it's like, are you just amplifying the problem? And from my perspective, having been in ministry and in business context, I'm like, oftentimes if we ran our ministries the way, if we ran businesses the way we run ministries, you wouldn't be in business for very long.

Yeah. and oftentimes there's this like, oh, but we're doing the Lord's work. So there's almost this like justification of the lack of process and this like over emphasis on uniqueness. We're working for God, so therefore we don't need good processes. We don't need to be good stewards.

Is that the idea? It's a bit of the unintended vibe, I think. And I think Cameron's point, it is more a lack of exposure and awareness. So I think to me, I could see...

For organization A, where it turns out that custom software actually does make sense, I could see a real mistake be that they tried to make custom software for all 10 of the unique problems when only two of them really should have had custom software. I think this is the process of building something that's custom, where you come in and you're like... We need to standardize on standard business practices for everything that we can and what is custom is custom Are you saying Cameron that the that like a part of the value of doing a custom build? Means that you are able to clearly audit your processes Whereas if you're getting something off the shelf you may not have have the need to you know answer some of those harder questions I think It's the input from the development team who have business exposure, maybe, or technology exposure, to be able to come along and say, here's what you can do standard, and here's what you need to do custom.

That feels like a scary bet, though. Will the development team or the people be charged with that actually have the experience to have that type of input? I'm not sure I'd bet on that in general. Mm-hmm.

I think it comes down to having the right team doing the development. If you pick a random developer from anywhere around the world, the chances of them having that experience are lower. But having a larger team who've been in business, who understand the challenges of business and also the challenges of ministry make that a smoother process. That sounds like that costs more.

I guess it can. But at the end of the day, you have a better outcome that will last longer. Stuff is built properly. I've seen too many projects in the church environment where they've gone to do something custom.

They've gone to someone who did it cheaply and they've actually never deployed it because it didn't actually fix and answer all those questions. So if I may, one of the challenges that I find with custom development because I like like to me this idea of identifying what's warranted or justified makes a lot of sense like why it doesn't make sense to try and just adapt to what zero in your example like has configured for small businesses and businesses in general when there's like a genuinely unique need of a ministry like that that makes perfect sense where I might look instead would be is there a more If I'm looking at accounting, for instance, is there like accounting software that's focused more on the needs of nonprofits and look at that before I would go and build like a custom accounting solution. But the challenge that I have and like with custom software is like how do you navigate the, what I would argue are potentially misaligned incentives because the development team that you work with is more likely than not in general motivated to say, you know what? we look at your 10 problems, we really think that five of them make sense to be custom, because that's a bigger scope, that's more cost, and they're still better off than if all 10 of them were, but it's like, who's taking that lens of like really asking those questions, because the development partner generally is incentivized for there to be more custom, because that's more work for them. That's one of the tensions that I find with custom that makes it difficult. is who's really advocating for whether or not you need it, especially if the buyer is not technical and doesn't have the experience to really know what questions they should be asking.

I'm not in your seat, Cameron, but I feel like there's something I just want to insert here as a potential point to consider there, and that is... That sounds to me like there is one, at least one party or one process missing from the system, right? If the person that is doing the work is not, if you're not trusting them, that's potentially problematic anyway, but ultimately you even need to have somebody that is going to advocate for the client to be able to say, this is actually what we need. or at least to have enough expertise to be able to intelligently interact with the customer. But that can be done in a formal way by engaging someone to do some discovery in a separate engagement before you commit to something else.

And I would just argue to clarify that I don't see it as about trust nearly as much as about just aligned incentives because a very talented software developer or development company or team Like, I'm not saying that there's anything like, wrong, quote unquote, with them building the five out of 10 things uniquely. But they're going to look at it through the lens, I'd argue a custom like development of like, well, custom is how we're going to do this. And, and that's probably what they know. And they may not be incentivized to even know what the state like the landscape is out there.

Right? Like what tools exist because they're so busy just trying to be good at custom development. So I I've experienced this what I would describe as an inherent like difficulty and I'd say it applies to both sides but if you're assuming custom from the outset I think there's a higher risk that you end up having a lot more that's unique than actually needed to be just by nature of the incentives of that development team to build unique things for you. ED is a tendency of developers I've watched them basically it's like if if your only tool is a hammer everything's a nail And I have seen so many developers do that.

They come at it from a technical development perspective, not a business operations perspective. And having a dev team, like the BlueVineyard team has got a very large scope. While I do a bunch of custom development, I've been in business since my, running a business with multiple staff since my early twenties. And I can tell by your gray hair.

Yep. 10 per staff member per year. I think it's probably a bit higher than that. But yeah, it's, I try to look at it and go, okay, what do we have to implement that is custom? But I want to implement the least amount of custom because standard processes that businesses use every day of the week is still better than something that is uniquely custom.

And just cutting that out and going, well, how about we actually think about this from a different perspective? And then let's only do custom what we have to do. Because developers will do it exactly how someone wants if they don't have that larger team with that experience. Developers are very good at following instructions to some extent.

Well, and one thing I would argue and so in favor of custom is like when the problem that you're trying to solve is really close to as I opened with like at the core of what your organization is trying to accomplish then software and especially in a world where the barrier to good software development is going down with all these like AI tools and like there it's the cost is actually going down to build this stuff. I think there's a lot of opportunity to especially if you're working with a good partner to like make connections that wouldn't have been obvious to the product like the the organization that's looking for this software based solution where suddenly whole new things could be possible where maybe they if it's donor based for instance like the the quality of their ability to interact with the donor and have things be automated but still be like really meaningful goes quite a bit up with your ability to do things custom so to me it goes back to If you're saying, hey, we need software for something, how close is that problem you're trying to solve to the core of your mission and focus as an organization? And I think the value for custom goes up the closer it is to your core, but also so does the risk and the importance of like you having confidence in that solution. So I want to kind of add another thing, Jonathan, to your point of Times be changing things are moving quickly and rapidly and There's there's two parts to this is that one?

Custom software is now easier to do I mean vibe coding is a thing not for obviously a lot of these types of solutions But it is a thing and will increasingly be more so Also, there are more off-the-shelf options or specific things in the market now than there ever have been. And that will be a continued trend. Example, there are, you know, maybe you would have had just a few like QuickBooks was the solution that everybody had a huge market share, but now there are a lot more bookkeeping, accounting types of options out there and accounting options that are maybe specific for fundraising that are specific for nonprofits that are specific for ministries. How do we think about All of these software options that are out there that a ministry, they've got their head down, they're doing the work, their job isn't to be technologists.

That's our job. How do we know about all the software that's out there that is more specific versus, nope, cut the, you know, like it just isn't specific enough. Cameron, I'm going to throw that one to you. How do we know when it's not specific enough versus software that's out there and what do we do about all the software we don't know?

I'll just jump to the vibe coded component before we jump over there. There's a lot of things there in there. AI is great to some extent, but the challenge that people don't realize is without the technical understanding of the business systems, ministry systems and technology and coding in general. AI is only a tool.

And if you don't use the tool right, you end up with more trouble. And the number of vibe coded apps that people have launched that have been total disasters have been not secured, have exposed hundreds of thousands of people's details. I can imagine that from a ministry perspective, they went and vibe-coded a component for their system, it's insecure, and next thing they know, all their ministry details, all their donor details are out, or maybe even people that they're trying to support and help. So I think these technology components need to be built within a framework that has a technology partner that's there to help ensure that things are done the right way.

What if the technology partner is doing the vibe coding? Then they aren't a real technology partner. I guess part of the point of maybe less specifically about vibe coding, but these technology partners have access to more to quickly create software more quickly than they've ever been able to do in the past. Yeah.

So I definitely use a lot of AI, but I have an understanding of the the larger scope of the project, but also the technical requirements, the security requirements. I generally define vibe coding more as someone who doesn't read the code and understand what is happening. And they just give it a description. I need a CRM and this is the information I need to capture. and they walk away and they come back.

That's sort of the definition of vibe coding. If someone's using AI in their development process and they're guiding it and it's just speeding up the process of development, I kind of put that in a different category. Got it. Yep.

From my perspective, it's just hitting me now. I think we're on a trajectory over the next couple of years where the line between custom and off-the-shelf is going to blur and come a lot closer together because part of what you're getting with AI already today and even more so in the future is generative interfaces, where the ability to create an interface around a particular problem set, the cost to do that is going to go continue to drop both in terms of time and the money to it. You'll be paying something else for it. So I think that line is going to become blurrier.

What does it mean to have something be off the shelf? Because I think you're going to get a not too distant future where like custom software is increasingly off the shelf in terms of you're able to go to like a particular solution. Now, at least in my mind, those three factors become even more relevant. And that is like how core is the thing that you're trying to solve to your like the heart of your organization?

Because I could see a as our confidence goes up in these tools. That's the other piece of it There will absolutely be like there's gonna be a lot more people who have ideas for software that are gonna be able to execute them and get something to market and that getting it to market and In any context whether it's nonprofit or commercial Is a really important piece of that puzzle that once validated because that's often the hard part once you say, okay This is actually solving a problem then working with a partner who understands that and can say, okay, now let's help this go to the next level. Let's help make this more stable. Let's think about the longer term.

So I think it's a great time to be thinking about software because that line is blurring. But thinking about your confidence in the solution and how does someone who doesn't know, how do they navigate, okay, well, what tools do I use for this? Especially with how quickly things are evolving and changing the space. So I think it's a great opportunity, but knowing how core the thing that you're trying to solve is to your organization's goals and mission, having a real world sense of the cost, because you're going to pay for it one way or the other, and your confidence in how you're going about getting that solution and who's behind it on the other side.

Would you also say, Cameron, I'm just curious, If you are, um, where would the consideration of costs come into that? One of the things that I think is important for ministries especially is ownership of their data. And a lot of the time with the hosted solutions, especially on some of the larger organizations, they have less of your ownership of your data. Yes, you own your data, but if you take that data out, it does not operate or function outside of the system.

And I think that is an important component for a ministry is to be able to, over the long-term, continue to use their data and have valuable insights from that data. I think that also comes into open source that helps with data ownership. But something that's custom allows the ministry to have their data presented in the way that they need, capture the data that they need, and nothing extra. And allows them to be very performant and optimized in how they run their day-to-day ministry.

If you've chosen a good partner for that, because custom can also be the nightmare in terms of like, yeah, we own the data, but what can we actually do with it? if it was poorly built or if it was built by a developer who preached that and that was no longer with the organization. They'd say, okay, what do we do about this now? I've seen more challenges over the years where they've used someone internally in the ministry to build something because ministries have a tendency to have turnover of staff. because it is ministry and a lot of these positions are volunteering, that sort of thing. And that's where I think a technology partner that is stable, that is there, is probably sometimes better than having someone in-house do it.

If you've got someone in-house that can work with the technology partner, that definitely makes it more streamlined. But we've... seen conversations with ministries that have built something years ago in-house and they're actually running something that is probably borderline to be secure because the product has not been, one of the components that they built with has not been continued to be updated. It's end of life. But Cameron, ministries never get hacked.

Like prayer keeps all that away. I wish it worked that way. The prayer firewall. If only it was that easy.

Um, one of the interesting things is, um, in Australia, the fines for a data breach are based on the amount of turnover that the organization has. And that is, uh, terrifying. Um, a lot of conferences in the Adventist church, they start, um, at around, I think it's about 10 plus million dollars if they have a data breach and they mishandle. That's the fine from the federal government, let alone the repercussions from destroying the trust that people have.

And that's something that ministries need to sort of factor in as well is how do we keep everything secure? And how do we make sure that we meet all the compliance requirements that we have from a a legal framework in whatever country you're operating in as a ministry. And like some ministries probably have multiple countries. They might be based out of a Western country that is their primary donor source, but they are working in a third world country or something like that, where you've actually got multiple legal frameworks.

So in Australia, the South Pacific Division covers Australia, New Zealand, Pacific Islands, and they also cover New Caledonia. New Caledonia is French and it falls under EU legislation, GDPR and all of that legislation. So everything that the church does for the South Pacific IT division department, they have to comply with GDPR legislation for New Caledonia, even though that's sort of the only place for the South Pacific that has that legislation. everywhere else falls under the Australian New Zealand sort of framework of legislation. So they've got Australia, New Zealand, and European legislation that they have to comply with, which can be a little bit more challenging to meet requirements of everyone.

And that to me strikes me as a good example of where if it's not really core to your business, going with a piece of software that's done the legwork to deal with compliance in multiple jurisdictions, because it's not realistic to expect like that to be in-house and effective. What will usually happen is it's compliance by obscurity or it's like you think you're compliant, but it hasn't been tested. When it's tested, that employee is probably not even at the ministry anymore. It's just like, well, just hoping that nothing happens here.

Yeah, too much stuff happens that way, but again it comes back to, like you said, is this a core component of your ministry? If it's a core component and you're spending enough time, have enough dollars being raised, and it's a critical enough component, and there isn't something sitting there, then it's definitely well worth doing that legwork to make sure you're compliant. It's probably in some ways less of a challenge for a ministry. The Adventist Church's South Pacific Division covers a large area, and that's sort of probably on the extreme end of those examples.

But I think a ministry that wants and needs something to be reliable, dependent, and to streamline their ministry, something that's custom definitely can meet those requirements of complying with everything. Well, without too much work, most of the requirements are around making sure that you do the best practice in the industry. And a good technology partner does that. If we set aside just the compliance piece for a moment, because while all that's warranted, I'd look at this through the lens of just like missional efficiency and effectiveness.

Like software can very much help you do what you're trying to do more efficiently and effectively, whether it's custom or off the shelf. While we do need to think about risk mitigation and management, and I think that's something that the Aventus Church as a whole has really matured in over the years, it's also important to think about this through the lens of how does technology help us do the thing that we're trying to do more efficiently and effectively? How can we get rid of more paperwork and have things be more streamlined for whatever it is that we're trying to do? And what are the new opportunities that technology bring to the table to help people make decisions more effectively?

Maybe it's to save time so they can focus on other aspects of the ministry. And there's there's a lot of upside, whether it's custom or off the shelf. And I think that that upside should be should be a consideration. And for folks, and this is where I think a good technology partner can be key here. is like, what are the questions that you didn't even know that you could ask about what's possible?

And a good understanding of what the ministry is trying to do, and its missional goals can say, oh, how about this? Have you considered this possibility over here? This way the technology could come in, whether it's off the shelf or custom. I really appreciate the context that both of you have brought to this.

This agreement disagreement, I appreciate that you've kept the expletives to a minimum as you are angry at each other and coming at that. No, it's as we're starting to wrap up this discussion, you know, let's kind of give a little bit of a face to this. Let's give a ministry that has been around for a while. What are some of the things that they need to be thinking about? first as they are addressing these inefficiencies in their business.

And we'll kind of wrap up with this. I started with Cameron before. I'm going to jump to Jonathan on this, and then we'll end with Cameron. I think the main thing is to just be as clear as you can be on what problems that you're trying to use technology to solve.

And how do those problems connect with the core, the missional focus of your organization? I think that's the heart of it because oftentimes the thing you're going to run into is you can't, someone making a decision can't possibly know all the options that are out there. And hopefully they've done some like exercise some curiosity and have some ideas going into it. But if you can be clear on what you're trying to actually get done.

So rather than going to either an off the shelf solution or a technology partner to build something custom and saying here I need X, Y, and Z, being clear on what are you actually trying to do, a good partner is going to be able to take that and connect that to the things they have already done and what worked and what didn't work for others and help you navigate whether you need custom or you can leverage something off the shelf. So I think just being clear on day to day, what are you trying to accomplish that you think software could help you with? and understand how that thing connects to your bigger goals as an organization, I think is really essential. Because with that being clear, the odds of you finding the solution, whether it's off the shelf or custom, that's a good fit that you can feel confidence in, that is a reasonable cost to go up significantly if you can clearly articulate what you're trying to solve and how that connects to your goals as an organization. And any good partner is going to be able to Like, they'll probably ask you this.

But if you know this going into it, it's going to help you much more effectively evaluate solutions. And this is, I think, the biggest thing I see missing in conversations is folks have the start of an idea. They're like, oh, we could use software for this. But they can't clearly yet articulate what are they really trying to solve and how does that connect to their mission and what they're trying to accomplish as an organization.

So starting there. Got it. Yeah. That internal work.

Thank you, Jonathan. Cameron, yeah, what would you like to add to that? Yeah, I think having a technology partner that's also ministry focused probably is a big component. One, they understand the context.

But two, they also understand that while a custom solution might be the perfect option, your budget as a ministry is only X amount. So what is the next best? option to help you achieve that with something off the shelf, something that's open source and helping guide you through that process and also having the understanding of business systems that can maybe be applied to the ministry to help with some of those challenges. I think that's sort of core component that makes the process run smoothly. So Yeah, I think that that's a great like two part conclusion, right?

You know, number one, understand your own needs as well as possible. Number two, make sure you partner with the right people to solve the problems. I think that's A good place for us to wrap this one up. Gentlemen, I thank you very much for sharing your expertise on the show.

And for those of you who are listening, if this is something that's been useful to you, feel free to share that with a friend or reach out to us on social media. We'd love to connect with you more there. And we will see you next time for the next episode of The Blue Vineyard Podcast. Thank you for joining us for this episode of The Blue Vineyard Podcast.

For more episodes, information about our services and more, please visit BlueVineyard.com.