I have zero web development experience. I have never been an engineer. And a few weeks ago I built a working playback app for our worship team, with stems, pads, song transitions and voice control, in about an hour of prompting. Luke Jackson and I sat down to show it, and to talk about what this shift means for churches. Watch the full conversation above, or read the highlights here.
What the app does
The app plays back audio stems for worship, the same multitracks you would buy from any stem provider and run in Ableton. It has a setlist, a library of songs, a pad player that holds a key under transitions, and the usual transport controls. Between songs you can choose how it moves on: stop, cross-fade, or carry the pad over.
Then it does things no off-the-shelf app did for me. While a song plays, I can say “let’s skip to verse two” and it cues the next section. If I change my mind, “nevermind, let’s stay in this section” cancels it. Picture a music director with a talkback mic routed straight into the app, giving cues out loud while playing keys, like having an automated playback engineer listening for what’s next.
It also understands the songs. On a track with no sections marked, one click on “detect from guide” listened to the guide cue track and wrote every section in, in a few seconds. Then I asked the built-in assistant to rearrange the song to verse one, chorus, verse two, chorus and end. It was done in under ten seconds. Luke has spent plenty of Saturdays clicking markers into Ableton by hand, and his reaction says it all.
What vibe coding actually is
I used Claude Code to build it. The name throws people off, because you don’t have to be a coder to use it. It works like any chat with Claude: you describe what you want, and it builds it. It uses more of your computer’s local resources than the browser version, and it still draws on your saved skill files, so it gets better at your work over time.
You don’t need to understand the computer science underneath. When the first version had audio glitches, I told Claude “I’m getting some audio artifacts, fix it.” It took about ten minutes, but it found the problem. Later it noticed on its own that the app was using 40% of my CPU while idle, went looking, changed one setting, and brought it down to about 2%. I would not have known where to look.
Once the app is built, it runs on its own as a normal Mac app. You aren’t spending AI usage every time you press play.
Every app is a compromise
None of this is a knock on the companies that make worship software. They do great work. But an app built for everyone has to make decisions for everyone, and somewhere a designer in another state made choices about how your tools should work. That is why, with whatever app you choose, there’s always some compromise, and why every new release fills the comment sections with feature requests.
Luke put it well: maybe your roadblock is budget. A lot of churches can’t buy one more subscription or license. Maybe you spend the Claude subscription and build exactly the thing you need. If an app only runs on Mac and your team is on PC, you can build one for your PC.
There are real questions to work through. Stem licensing still matters; you buy the right to play tracks back, wherever they’re played from. And who supports custom software? So far, Claude has. When there’s a bug, you’re the person directly connected to the app, a chat away from the fix.
Software engineers no longer hold the keys
The bigger idea is this: software engineers no longer hold the keys to the kingdom. You can be the software engineer now. That changes what’s possible for churches that have always felt a step behind on technology, the last to get LED walls or new video formats because there’s no capital budget for them.
We’ve seen it at Churchfront. Building our own tools with Claude has saved us easily $50,000 to $60,000 a year in software services, and it has given us time back. I didn’t start Churchfront to be a procurement or logistics person. I started it to equip church leaders with solutions for thriving ministry. We’ve taken some flack on this channel for talking about AI in the church, and we’re going to keep talking about it, because it can be used for better or worse, and we believe churches should use it for the purposes of the kingdom.
Start with your own “what if”
Think about the part of your weekly workflow that slows you down. Ask Claude what it would take to fix it. The answer might be a simple app with a click track, a guide and some pads, or it might be something no one has built yet.
If you’re planning a new system or rethinking the one you have, our team would love to help. Talk with Churchfront.
As a Senior Developer(38yrs) by day who works at company that actively uses AI to make our developers more efficient I have to ask how you are ensuring that AI did not include things that might compromise security on your systems? AI is definitely changing the landscape of building tools and apps but it also comes with added risks as have been seen in the news. One suggestion is to have a different AI model review the code for vulnerabilities. To summarize, be careful putting blind faith into AI!
Nate here,
As a SWE, I will highlyside with Bob EWY , code is now cheap, Likes of Opus and Astra and Fable can spit out working apps out in a day but please use them internally and as he said get a review platform eg code rabbit or other models to actually code check your app because I can highly bet right now if you give me the source code I’ll find vulnerabilities that opus missed out and you can imagine the more people spit out “It just works” apps the more bad actors are spinning up to actually compromise those apps and I bet the last thing a church really needs is getting compromised because claude code missed out on setting a security wall on certain feature on your vibecoded app. I personally use AI but it has alot of testing, I check, I review and ensure it absolutely works as intended.