One Song, One Key, Every Musician Ready: Cris Barrion Built Her Church Team an App Called Team Yeshua

Every church music team on earth knows a particular kind of Sunday morning. The service starts in a few minutes. The songs were chosen days ago, everyone practiced, more or less, and yet the paper on the music stands does not agree with itself. The guitarist learned the song in the key of G, because G is the key of the recording everyone knows. The singer needs it lower, because G sits too high for her voice early in the morning. The bassist is working from a chart printed off a website long ago, in a key nobody can quite identify, with a bridge the team voted to skip weeks back and never told the paper about. The keyboard player has the current chart, the one from the group chat, which means exactly one person on the team is fully informed. So, minutes before the first song, the team does the only thing it can do. It negotiates. Keys get called out across the platform. Capos slide up and down necks. Somebody transposes in their head, on the fly, while someone else counts in.

Notice what this scene is not. It is not a talent problem. Every musician in that huddle may be genuinely good. It is not an effort problem either, since most of them practiced during the week, alone, with real discipline. It is an information problem wearing a musical costume. The team does not have a shared, current, single version of the truth about its own songs. Each musician holds a private copy, the copies drift apart over time, and the drift only becomes visible at the worst possible moment, when the whole room is watching and the countdown is real.

Once you see it this way, you start seeing the same failure everywhere. A small business where the price list lives in three spreadsheets, none of them current. A family where the recipe exists in four handwritings and one memory. A software team where the documentation describes the product as it was two versions ago. Groups rarely fail because nobody knows anything. They fail because everybody knows something slightly different, and the differences collide in public. Coordination is not a soft skill layered on top of the real work. For any group that performs together, coordination is most of the real work.

This is a story about a web developer in the Philippines who looked at that exact problem inside the group she loves most, her church music team, and built the tool that fixes it. Not a startup. Not a product launch. A private web app, built with AI assistance, for a handful of worship musicians, that puts setlists, songs, and chords in one place, shows every musician the same song in the same key with the same chart, and then, quietly, goes one step further and teaches the newest guitarist how to become good enough to play it all. Her name is Maria Criselda Barrion. The community knows her as Cris. The app is called Team Yeshua.

The troubleshooter from Tayug

Cris Barrion is a WordPress Developer and Web Support Specialist from Tayug, Pangasinan, in the Philippines. She has spent nearly four years maintaining, updating, and troubleshooting websites. Sit with that job description for a moment, because it is easy to skim past and it explains everything that follows. Maintenance is the unglamorous end of the web. It is the work of keeping other people's sites alive: updating what needs updating, adjusting what needs adjusting, and digging in when something breaks at an inconvenient hour and a client needs it fixed before their customers notice.

Her skill set, as listed on her AI Pro profile, reads like the inventory of a working web generalist: WordPress development, Elementor page building, HTML and CSS adjustments, website performance optimization, technical troubleshooting, and SEO support. None of these are the skills people put on conference posters. All of them are the skills that decide whether an ordinary business's website earns its keep on an ordinary Tuesday. She also worked with recurring task workflows in ClickUp for SEO fulfillment across clients, which means a slice of her working life has been about systems that repeat: tasks that fire on a rhythm, for many clients at once, where the whole point is that nothing falls through the cracks.

And there is a telling detail in her profile about temperament. She enjoys the troubleshooting end of the job most: finding solutions to website issues, and making sure content is presented accurately and consistently. Read that twice. Accurately and consistently. The thing she likes best about her work is the pursuit of a single correct version, presented the same way everywhere it appears. If you were casting the role of person who would eventually build an app whose entire purpose is one song, one key, and one chart in every musician's hands at the same time, you could not do better than a support specialist whose favorite thing is accuracy and consistency.

Support work teaches a builder things that greenfield development never does. It teaches you where real people actually get stuck, because you spend your days reading their stuckness in ticket form. It teaches you that the fanciest feature is worthless if the content underneath is wrong, out of date, or shown differently to different people. It teaches you to respect the recurring task, the weekly rhythm, the unglamorous loop that has to run correctly fifty two times a year. A worship team, not coincidentally, is exactly that kind of system. It performs on a weekly rhythm. It rotates people. It carries a library of material that grows over time. And it falls apart in predictable places: the handoffs, the versions, the keys. Cris spent nearly four years being paid to notice precisely those failure modes in other people's systems. Then she turned around and noticed them in her own team's.

From keeping websites alive to building something of her own

There is a familiar arc in the story of how working developers met AI, and Cris's version of it is refreshingly unexaggerated. She uses ChatGPT regularly, for research, writing, troubleshooting, and building projects. She has used Claude Pro for about a month, for writing and technical research. That is it. No claims of ten x productivity, no tales of replacing an entire team with a prompt. Just a support specialist who added two AI tools to her working kit and used them the way she uses everything else: to find solutions and to build things.

But notice what AI assistance changes for someone in her position specifically. A support specialist's knowledge is broad by necessity. She touches design tools, page builders, code, performance, search, and content in a single week. What she historically could not do alone was ship a full custom application, the kind with a real database behind it and a front end built from scratch, because that is a different trade, with its own years of apprenticeship. AI assistance collapses that distance. It does not hand her the judgment, which she already has from four years of fixing real systems for real clients. It hands her the leverage: a patient collaborator for the unfamiliar parts, so that the judgment she earned maintaining other people's websites can finally be expressed as a system of her own.

That is the deeper pattern this story keeps returning to. The people getting the most out of AI tools are rarely the people with nothing. They are the people with a craft, a community, and a concrete problem, who were previously blocked by one missing layer of capability. Cris knew exactly what her team needed. She knew it from the inside, the way only a person who lives inside a problem knows it. What she needed was a way to build at a level her day job had never required. AI help throughout the build is the bridge between those two things: the knowing and the making.

She is also, notably, looking ahead. Her profile says she is currently exploring MCP, the Model Context Protocol, as tooling to connect agents to real work systems. Hold that thought. It is the direction her whole story points, and we will come back to it at the end.

Inside Team Yeshua

Team Yeshua is a web app Cris built for her church music team. It is built in React and connected to Supabase, with AI assistance throughout the build, and it puts three things in one place: worship setlists, songs, and chords. Before we walk through what the app does, two facts about it deserve to be said plainly, because they shape everything about how to think about it.

First, it is private. Team Yeshua was built for her own worship team, and there is no public link. You cannot visit it, and this post will not pretend otherwise. The screenshots of it on her AI Pro profile are her own, shared with her permission, and they are the window the outside world gets. Second, and related: the app was never meant for you. It was meant for a specific small group of musicians who play together every week. That narrowness is not a limitation of the story. It is the story. Some of the most instructive software in the world right now is being built at exactly this scale, by people like Cris, for teams they can name.

The choice of stack tells you she built it as a real application rather than a mockup. React is the front end, the part the team touches. Supabase sits behind it as the connected data layer, the place where the setlists, the song library, and the chord charts actually live. That architecture matters because of the problem from our opening scene. Paper fails because every copy is a separate object that can drift. A web app with one shared store of data fails differently, or rather, it mostly does not get the chance: there is one setlist, one library entry per song, one chart, and every screen the team opens is looking at the same underlying thing. Update it once, and it is updated for the bassist, the keyboard player, and the singer simultaneously. The single source of truth is not a feature of the app. It is the app's founding idea.

The home screen lays out the team's whole Sunday in four parts. There are Setlists, to organize worship songs from opening to closing. There is the Song Library, to browse and prepare the team's songs. There is Get Your Key, a tool for finding a comfortable starting key for your voice. And there is Team Yeshua Learning, the teaching wing of the app, which we will spend real time on shortly, because it is the part that turns a good tool into an unusual one.

Consider how much of a worship team's weekly friction those four doors quietly absorb. Building the setlist is the leader's planning work, the arc of a service from opening song to closing song, and it lives next to the library it draws from. Preparing for Sunday is each musician's private work, and the library is where that preparation starts. The key question, which causes the Sunday morning negotiation in our opening scene, gets its own dedicated tool instead of an argument. And the growth of the team's newest players, which in most groups depends on whoever has spare time to teach, gets a permanent home. Four doors, four distinct jobs, one small app. That is not an accident of design. That is what happens when the person specifying the software has personally lived every one of its use cases.

Two of those doors deserve a slower look, because together they describe something every team has and few teams protect: a memory. The Song Library is where the team's songs live, to browse and to prepare from. A team's repertoire is an asset built slowly, song by song, Sunday by Sunday, and in the paper world it has no home. It exists as a pile of charts in a folder, a folder inside a bag, a bag in the corner of a room, plus whatever each musician privately keeps. Songs the team knows well quietly fall out of rotation because nobody remembers they exist. Songs get relearned from scratch, at rehearsal prices, because the team's version, the one with the right arrangement and the agreed changes, was never written down anywhere durable. A library ends that amnesia. The repertoire becomes a collection the team owns together, visible to everyone, ready to be drawn from when the setlist is built.

And the setlist itself, in this design, is more than a list. To organize worship songs from opening to closing is to shape an arc: how a service begins, how it gathers energy, where it rests, how it ends. Worship leaders think about that arc the way editors think about the order of chapters, and they usually have to think about it in their heads, or in a message thread that scrolls away. In Team Yeshua the arc is an object in the app, sitting beside the library it was drawn from, visible to the whole team at the same time. Preparation flows from it naturally. A musician opens the setlist, sees the songs in their order, opens each one in the library, and prepares against the same material everyone else is preparing against. The leader's plan and the player's practice stop being separate documents that might disagree. They are two views of one thing, which is, once again, the founding idea of the whole app, expressed at the level of the week instead of the level of the song.

The chord chart is the whole argument

If you want to understand Team Yeshua, spend your time on the chord chart, because the chord chart is where the app's philosophy becomes visible. A chord chart looks like the simplest document in music: the lyrics of a song, with chord symbols placed over the words where the harmony changes. Every church musician has handled hundreds of them. And yet the chart is precisely where teams bleed, because a chart is not really a document. It is a coordination device. Its job is to make six people, playing four or five different instruments, do the same thing at the same moment, and its failure mode is silent: everyone follows their own chart perfectly, and the charts disagree.

Open a song in Team Yeshua and the app shows the chart the way a worship musician actually needs it. The chords are laid over the song's sections, intro and verse and the rest of the structure, so the harmony is anchored to the shape of the song rather than floating as an abstract list of chords to memorize. Sections matter more than they might seem. A chart organized by section teaches the player the architecture of the song while they play it: where the energy enters, where it rests, where the chorus lifts. It turns practice from memorizing a sequence into understanding a structure, and structures are what survive the nerves of a live service.

Then comes the detail that reveals the builder's instincts. The same chart can be viewed three ways: a guitar view, a bass view, and a keyboard view. This sounds like a small convenience until you think about what the three instruments actually do with harmony. A guitarist needs chord shapes, fingerings that hands can hold. A bassist needs the roots and the movement between them, the floor of the harmony rather than its full voicing. A keyboard player needs the chords in a form suited to keys and inversions. One song, one underlying chart, three honest translations of it, each matched to the hands that will use it. Nobody has to transcribe anyone else's version by ear the night before. Nobody's copy can silently fork from the master, because there are no copies. There is one chart, viewed from three chairs.

The app also shows chord diagrams for each shape, right there with the chart. A diagram is the picture of where the fingers go, and including it inside the chart, rather than in some separate chord book or a search result, removes one more small excuse for drift. When a player meets an unfamiliar shape midweek, the answer is on the same page as the question. And for the learning itself, there is a practice mode, for working on the song before Sunday. The distinction the app draws is a mature one: the chart is for performing, the practice mode is for preparing, and conflating the two is how musicians end up trying to learn in the middle of the performance. Preparation gets its own space, with its own tools, so that Sunday itself can be about the song rather than about survival.

Her profile sums up the problem all of this solves in one line, and it is worth quoting exactly, because no paraphrase improves it: the value is the same song, in the same key, with the same charts, in every musician's hands at the same time. Read that as an engineer would. It is a statement about consistency across distributed copies, the exact quality Cris says she enjoys most in her day job. The chart feature is her professional temperament, accuracy and consistency, rebuilt as software for the people she makes music with. The bassist in our opening scene, stranded with the mystery chart from two years ago, is the user this feature was designed to rescue. In Team Yeshua, that rescue is not a policy or a reminder in a group chat. It is structural. The old chart cannot follow him into the app, because the app only holds the current one.

Get Your Key: the singer's problem

The third door on the home screen has a playful name and a serious job. Get Your Key exists to find a comfortable starting key for your voice. It deserves a section of its own, because the choice of key is one of those invisible decisions that quietly decides whether a song soars or strains, and in the average worship team it is made by habit, by the recording, or by whoever speaks first, which is to say it is often not really made at all.

Think about what a key actually is for a singer. A song's melody lives in a range, a span from its lowest note to its highest. Every voice also lives in a range, and the two ranges either fit each other or they do not. Put the song in the key of the famous recording, and the melody may sit exactly where the recording artist's voice is strong and exactly where your team's singer is not. She spends the whole song reaching, or sitting so low that the words lose their energy, and the congregation feels the strain without ever knowing its cause. Move the song to a key fitted to the actual voice in the actual room, and everything changes without anything else changing. The melody sits in the strong part of the range. The singer can think about the words instead of the notes. The key is not a technicality. It is hospitality, measured in semitones: the decision to set the song where the people singing it can genuinely sing it.

Now connect that back to the chart. In a paper world, changing the key is expensive, which is why it so often does not happen. A new key means new charts for every instrument, reprinted or reworked by hand, with every manual change a fresh chance for error and drift. The cost of the change is so visible that teams endure ill fitting keys for months rather than pay it. In an app built around a shared song library, the key becomes a property of the performance rather than a thousand edits scattered across paper. Get Your Key makes finding the comfortable key a deliberate step, a thing a singer does on purpose, in advance, instead of a discovery made in front of a congregation. The tool does not just store the decision well. It makes the decision cheap enough to make properly.

There is a leadership lesson folded inside this small feature. The best tools do not merely record the judgments a group has already made. They lower the cost of making the judgments the group keeps avoiding. Every team has a version of the wrong key: the thing everyone endures because fixing it is tedious. Watch what a builder chooses to make cheap, and you learn what she thinks her team deserves relief from. Cris made the singer's comfort cheap. That tells you how she listens.

The app that teaches: Team Yeshua Learning

Most tools stop at the job. The setlist is organized, the library is browsable, the charts agree with each other, the keys fit the voices. A builder could ship exactly that and call it done, and it would be a genuinely good piece of software. Cris built one more room into the house, and it is the room that changes what the app is. Team Yeshua Learning carries the tagline, in her own words, grow as a worship guitarist, one note at a time. The app does not only coordinate the team that exists. It grows the team that is coming.

To see why this matters, consider the quiet crisis built into every volunteer music team. Teams run on a small number of experienced players, and experience is a bottleneck. When the team's guitarist is away, the songs get simpler or the Sunday gets thinner. When a new player joins, full of willingness and half formed skill, somebody has to teach them, and teaching takes the one resource volunteers never have, which is time together outside the service itself. Most teams solve this with hope. The new guitarist is handed the setlist, pointed at the recordings, and wished well. Some thrive. Many quietly stall at the edge of the team, able to play the easiest songs, locked out of the rest, because nobody ever gave them a path from where they are to where the setlist lives.

Team Yeshua Learning is that path, built into the same app that holds the setlists. And its curriculum, per her profile, starts where a new team guitarist actually is. That phrase deserves respect. A great deal of music instruction fails by starting where the teacher wishes the student were, with theory and terminology that assume a map the beginner does not yet have. Cris's lessons start with what a beginner's hands already know: familiar chord shapes. Specifically, they start with the CAGED system, and it is worth explaining what that is, because it is the intellectual hinge of the whole learning wing.

Here is the idea. A beginning guitarist learns a handful of open chords, the first shapes every hand learns, and among them are five major shapes whose initials spell a word: C, A, G, E, and D. CAGED. The insight of the system is that these five shapes are not merely five chords. Repeated and connected, they tile the entire neck of the guitar. Any chord, anywhere on the fretboard, in any key, can be understood as one of these five familiar shapes moved to a new position. The neck stops being a hundred anonymous frets and becomes a repeating pattern of five shapes the player already has in their hands. The familiar becomes the map of the unfamiliar. For a new worship guitarist staring at a setlist in an unfamiliar key, this is the difference between a wall and a door: the song's chords are not new objects to fear, they are old friends wearing new positions.

Around that core, the Learning wing adds the essentials a team guitarist needs first: essential chords, the working vocabulary of the music the team actually plays, and an interactive fretboard for finding chord tones in standard tuning. Chord tones are the notes that make up a chord, and being able to find them anywhere on the neck is what turns shape memorization into musicianship. The interactive fretboard makes that exploration into something you do with your hands on the screen rather than something you read about. And the through line of the design is that none of this lives somewhere else. The lessons are in the same app as the setlist they prepare you for. The distance between learning the craft and using the craft is one tap, inside one tool, built by one person who understands both ends of it.

Step back and see what Cris actually built here. Team Yeshua is an onboarding tool disguised as a team app. The newest guitarist does not just receive the setlist; she receives, in the same place, a way to become good enough to play it. The team's knowledge stops living exclusively in its most experienced member's head, where it is vulnerable to every absence and every busy season, and starts living in a system that hands it to whoever needs it next. Organizations spend fortunes trying to capture exactly this, the transfer of craft from the people who have it to the people who are coming. A worship team in Tayug gets it because their web developer decided the app should teach.

The support desk is a school for builders

It is worth pausing to trace where this design sense came from, because it did not come from a design course. It came from the day job, and the clearest thread is the recurring system. In her SEO fulfillment work, Cris worked with recurring task workflows in ClickUp across clients: work that repeats on a cadence, where the value is not brilliance in any single instance but reliability across all of them. A worship team is the same shape of problem. Sunday is a recurring task. It has inputs, the songs, the people, the keys. It has a deadline that does not negotiate. It fails in the seams between people, not in the people. Her whole career has been seams: between a client and their website, between a task and its owner, between content and the accuracy of its presentation. Team Yeshua is a seam fixing machine, built by a seam specialist.

Troubleshooting deserves its own word here, because it is the habit underneath everything. A troubleshooter learns to ask a question most people skip: not what is this problem called, but where exactly does it live? The Sunday morning negotiation is a symptom. Where it lives is in the copies, the versions, the absence of a shared source. Another builder might have made a prettier chart. Cris made the chart impossible to fork, because she located the problem correctly. When you spend nearly four years finding solutions to other people's website issues, you develop a reflex for the difference between the complaint and the cause. Software built by troubleshooters tends to be quieter and more useful than software built by visionaries, because it is aimed at the cause.

And then there is where she is heading next, which her profile states with the same plainness as everything else in it. She is exploring MCP, the Model Context Protocol, tooling to connect agents to real work systems. Put her story in sequence and the trajectory is elegant. First, AI as a tool she uses: ChatGPT for research, writing, troubleshooting, and building, Claude Pro alongside it. Second, AI as a collaborator in the build: a full application, hers, shipped for her team with AI help throughout. Third, AI as something connected: agents wired into real work systems, so the assistance stops being a chat window you visit and becomes part of the workflow itself. Each step keeps the human in the same place, at the center, with the judgment. What changes is the reach of her hands. A support specialist from Tayug is methodically extending her reach, one layer at a time, and Team Yeshua is the layer where her own community got to feel it first.

Lessons for builders

Build for people you can name

Team Yeshua was not built for a market. It was built for a specific team, whose members Cris knows, whose voices she has heard strain in the wrong key, whose new guitarist she has watched hesitate at the edge of the setlist. That specificity is why the design is so sharp. A builder designing for everyone designs for no one's actual Sunday. A builder designing for her own team's actual Sunday includes Get Your Key, because she has heard the singer's problem with her own ears, and includes the Learning wing, because she knows exactly which guitarist needs it. If you are learning to build with AI, the fastest route to software that matters is not a bigger audience. It is a nearer one. Find the group whose recurring pain you personally witness every week, and build for them first. The constraints of a real, named community are not a compromise. They are the design brief.

Private is a feature

In a culture that measures software by launches and links, a private app can look like an unfinished one. Team Yeshua suggests the opposite. Because it is private, it can be perfectly fitted to one team's songs, keys, and people, with no compromises for strangers. Because it is private, its data is the team's own business and nobody else's. And because it is private, its builder could finish it, which is the most underrated virtue in all of software. How many public products die half built because the audience was imagined and the motivation ran out? Cris's audience rehearses with her every week. The motivation renews itself every Sunday. When you build for love, small and finished beats grand and abandoned, every single time.

Teach inside the tool

The Learning wing carries the most transferable lesson in this story. Whatever your team uses your tool for, some of your users are beginners at it, and their growth is either your tool's job or nobody's. Cris did not write a separate course and hope the new guitarist found it. She put the lessons where the setlists live, so the path from being handed a song to being able to play it never leaves the app. She also designed the curriculum the way good teachers do: it starts where the learner actually is, with the shapes already in their hands, and it grows one note at a time, to borrow her tagline. If your tool has users who are still becoming, build the becoming into the tool.

Make the avoided decision cheap

Every group endures some version of the wrong key: a decision everyone knows is wrong, left in place because changing it costs too much effort. The builder's question is always the same. What does my team keep enduring because the fix is tedious, and how do I make the fix nearly free? Cris's answers were a shared chart that cannot drift, a key finder that turns an argument into a step, and lessons that turn a bottleneck person into a system. Look at your own team's tedious endurances with a troubleshooter's eye. One of them is your first real product, waiting.

Why this belongs at Starvard

Starvard exists for a particular kind of story: ordinary people, far from the famous centers of technology, using the tools of this moment to build real things for real communities, and getting genuinely better at the craft as they go. Cris Barrion's story is that story at its purest. A WordPress support specialist in Tayug, Pangasinan, took the judgment she earned over nearly four years of keeping other people's websites accurate and consistent, added AI assistance at exactly the layer where she needed leverage, and produced a working system that her church music team relies on: one song, one key, the same charts in every musician's hands, and a learning path that turns beginners into band members. No hype attended any of it. There is not even a public link. There is just craft, pointed at love, working every Sunday.

It also belongs here because it teaches the deepest lesson this university keeps circling: the future of building belongs to people who know a real problem from the inside. The tools will keep getting easier to use. What will stay scarce is the troubleshooter's eye, the knowledge of where things actually break, earned in unglamorous work, in support queues and recurring workflows, in rooms where the chart did not match the key. Cris has that eye, and she is already looking at what comes next, connecting agents to real work systems through MCP. We will be watching where she points it.

You can read Cris's full story, in her own profile, at her AI Pro page: aipro.fm/cris. And if you are a builder with a craft, a community, and a problem you know from the inside, you would fit right in among the people gathered there. Come and meet builders like her in the E2 Discord: e2.life/join. Bring the problem your group keeps enduring. Somebody in that room has probably started building its fix.

Watch

Intro to Supabase: Full Tutorial for Beginners by freeCodeCamp.org: Team Yeshua is a React front end connected to Supabase, and this full course shows what that pairing can carry, building a real React app with authentication and real time data on the same backend Cris chose.

Getting Started with LiveChordCharts: from a copied chart to the stage by LiveChordCharts: Watch a worship chart travel the exact road this post is about, from a copied page to a transposed, setlist ready song on a stage tablet, and count how many of Cris's design decisions you spot along the way.

Once You See This Pattern, The Guitar Fretboard Gets Much Smaller by Ricky Comiskey: Team Yeshua Learning is built on the CAGED system, and this lesson shows the heart of it beautifully, one pattern of familiar shapes connecting the whole neck until the fretboard feels half its former size.

Sources

Cris Barrion's AI Pro profile, including her skills, her AI tools, and her account of Team Yeshua and Team Yeshua Learning: aipro.fm/cris.

Team Yeshua is a private project built for Cris's own church music team. It has no public link, and nothing in this post should be read as an invitation to visit it. The descriptions and screenshots of the app referenced here are Cris's own, shared with her permission on her profile.

This post was reported from the AI Pro profiles gathered in the E2 Discord, where Cris and the other builders in this series share their work.