What Happens When Your Camp Systems Stop Getting in the Way?

How listening to camp leaders is shaping better systems for sustainable growth

Camp technology is supposed to make life easier, but for many camps, it can feel like the opposite. Registration lives in one system, contracts live somewhere else, calendars are maintained separately, and important operational details get passed around through email, spreadsheets, whiteboards, printed schedules, walkie-talkies, and staff knowledge. Each tool may solve a particular problem, but together they can create what the team from The One App describes as a kind of “digital duct tape”—a collection of disconnected systems that camp staff have learned to hold together because that’s simply how the work has always been done.

That frustration is at the center of this episode of the Grow Your Camp Podcast, where Carl Lefever and Mark P. Fisher sit down with Michael John Stanley (MJ), Alan Brown, and Lindy Pinkerton from The One App. Their story didn’t begin with a group of software developers sitting in a room deciding what features camps ought to have. It started with years of working alongside camps, seeing the same operational frustrations repeatedly, and eventually deciding to go directly to camp leaders and ask how the work was actually getting done. That listening process began with visits to 10 camps, grew into conversations with roughly 60 camps, and continued through beta testing with camps using real groups, campers, schedules, and transactions.

What they discovered was that building technology for camp is unusually difficult because a camp isn’t a simple business with a few predictable workflows. As Alan puts it during the conversation, “You’re basically running a city at a camp.” Housing, meals, meeting spaces, activities, registration, maintenance, housekeeping, guest groups, programs, sales, and communications all overlap—and every camp seems to arrange those pieces a little differently. The result is a larger question that runs through the episode: What would happen if camps stopped having to reshape their operations around their software and instead had technology flexible enough to work the way camp already works?

Quick Camp Marketing Tip: Stop Marketing What You Have—Market What Guests Get

Before getting into the technology conversation, Mark shares a marketing principle that actually connects nicely with the rest of the episode: WIIFM, or “What’s in it for me?” Whether camps like it or not, that’s the question parents, pastors, youth leaders, and retreat planners are asking. They aren’t primarily wondering how many acres the camp owns or when the dining hall was renovated. They’re wondering whether their kids will be safe, whether their students will want to come, whether the experience will make their job easier, whether their group will grow closer, and whether God might use their time at camp to change someone’s life.

The mistake, Mark says, is that camps tend to talk about what they have instead of what the guest gets. Two hundred acres is a feature; room to unplug, breathe, and reconnect is the benefit. A high ropes course is a feature; students doing something difficult together and discovering they’re capable of more than they thought is the benefit. Even something as basic as providing meals has a larger value. As Mark jokes, “Congratulations. So does Costco.” What matters to a retreat leader is that someone else is planning, shopping, cooking, and cleaning so they can spend that time with their people.

“We talk about what we have instead of what they get.” — Mark P. Fisher

That gives camps a simple test for almost any piece of marketing. Before something goes on the website, into an email, onto social media, or into a brochure, ask “Why should they care?” and keep rewriting until the answer is obvious. Guests don’t really want cabins, meals, acreage, and zip lines for their own sake; they want what those things make possible.

Three Different Paths Into the Same Camp Technology Problem

One of the more interesting parts of The One App story is that MJ, Alan, and Lindy arrived at this problem from very different directions. MJ likes to say that “camping found me,” and his story began in the 1990s at Arrowhead Springs Christian Conference Center. He hadn’t been looking to get back into sales, but he fell in love with camp and became particularly involved with guest groups. At the time, he remembers the group side of camping getting far less attention than traditional programs, in part because so many camp systems had originally been built around summer camp registration and groups had been added later.

Over time, MJ moved further into helping camps with sales, marketing, and SEO, and that eventually produced an idea: create something like Hotels.com for camps so retreat and group leaders could more easily find the right property. But as he and Alan began looking at what it would take to make that work, they discovered a more fundamental problem. The technology infrastructure underneath camp operations simply wasn’t set up to support the vision. Around the same time, Alan had been thinking about a broader software question: Why is so much business software built to manage individual departments rather than helping the whole organization work together?

Alan hadn’t intentionally chosen camping as the place to answer that question. His background included problem-solving work in other industries, including airlines and Disney. But MJ challenged him to test his idea in camp because camps are extraordinarily complicated organizations. A camp may be managing lodging, food service, facilities, activities, maintenance, housekeeping, sales, programs, guest groups, and registration all at once, with staff regularly moving between roles. If a connected software architecture could handle that environment, they knew they might be onto something.

“You’re basically running a city at a camp.” — Alan Brown

Lindy came to the same problem from inside camp operations. Camp had been part of her life since childhood, first as a staff kid and camper and later as a summer employee at River Valley Ranch in Maryland. Eventually she returned to work there full-time as an event coordinator, although—as anyone who has worked at camp knows—that title only describes part of the job. She had also been a cook, counselor, activity staff member, and whatever else camp needed at the moment. One day might involve office work and the next washing dishes, clearing dining-room tables, or chasing horses that had escaped their fence.

Those experiences gave Lindy an unusually broad view of what it takes to make a camp function, and that perspective became even clearer when she later began working in camp marketing, sales, and consulting. Again and again, she encountered organizations running on five, ten, or even fifteen platforms alongside countless spreadsheets. Information had to be manually transferred from one place to another, communication was fragmented, and every handoff introduced another opportunity for human error. In some cases, even something as basic as a contract still involved sending a PDF that someone had to print, sign, scan, and return.

“Everything is fragmented.” — Lindy Pinkerton

Working with Mark through Inspiring Growth pushed that frustration toward a more specific question: Could they find one system that actually handled the way camps needed to operate? Lindy began researching products and sitting through demos, sometimes discovering within the first few minutes that a system couldn’t do what they needed. That search eventually led her and Mark to identify the Five C’s they believed needed to work together: contracts, calendars, communications, CRM, and coordinating. When Lindy later saw what Alan and MJ were beginning to build, the pieces started coming together.

Building Camp Technology by Listening to Camps

Identifying the Five C’s gave the team a clearer picture of what camps needed, but they still didn’t assume they understood how to build it. Instead, MJ and Alan decided to go directly to camps and learn how the work actually happened. In typical MJ fashion, that became an ambitious plan: spend about six weeks visiting 10 different camps, stay on-site, meet with staff across departments, and ask a lot of questions.

For Alan, one of the most memorable stops began with a January trip to Grace Adventures in Michigan. After landing in snowy conditions, he and MJ were picked up by camp director Steve Prudhomme for an hour-long drive to camp. Alan remembers sitting in the back while Steve navigated by watching the snowbank along the side of the road, leaving Alan wondering why he wasn’t looking straight ahead. When Alan asked what would happen if there were another car in front of them, Steve’s basic response was that nobody else was crazy enough to be driving in those conditions. Somehow, the white-knuckle trip was an appropriate introduction to what came next: getting inside camps and discovering just how complicated their operations really were.

Once they arrived, they sat down with people across departments and asked them to explain what they actually did. That was important for MJ because his own experience was strongest on the guest-group, sales, and marketing side of camp. He didn’t pretend to understand every part of operations. His thinking was essentially, I don’t know what I don’t know, so let’s sit with the people who do. Those conversations gave the team a much clearer view of the processes happening behind the scenes—and helped MJ recognize something particularly important about Christian camps.

Christian Camps Have a Habit of Saying “Yes”

One of the biggest things MJ learned on the road was just how flexible Christian camps tend to be. Their instinct is often to find a way to serve the person or group in front of them rather than telling them they don’t fit the standard offering. That willingness to say yes is a strength of camp ministry, but it also creates an enormous challenge for technology.

A camp might run traditional summer programs while also hosting guest groups, renting cabins, operating a campground, opening a swimming pool to the community, serving homeschool groups, or doing several of those things simultaneously. Another camp may offer many of the same things but organize them completely differently. That means software designed around one fixed definition of how a camp “should” operate quickly starts creating problems.

“Christian camps tend to say yes to everything. So they need software that can do yes to everything.” — MJ

That realization pushed the team further toward customization. MJ describes the idea almost like Legos: camps need pieces they can assemble around their own operation rather than one rigid structure they have to squeeze themselves into. The goal wasn’t to tell camps how meals, lodging, activities, programs, or guest groups should work. It was to give them enough flexibility to build those processes around the way their camp already serves people.

Ten Camp Visits Became Roughly 60 Conversations

The initial road trip was only the beginning. Lindy eventually met with roughly 60 camps, often spending around two hours in each conversation and sometimes meeting with the same camp more than once. She wasn’t simply collecting a wish list of software features. Her questions were much more practical: How are you doing this now? What’s working? What’s not working? Where are you getting stuck?

Then she would show camp leaders what the team had built and listen to their responses. Someone would ask whether the system could handle a particular situation or whether something could work differently. Lindy would take notes, bring them back to Alan and the development team, and those conversations would influence what they built next. In that sense, camps weren’t simply potential customers being shown a finished product; they were helping expose the realities the product needed to accommodate.

Eventually, eight camps began beta testing the system with real data, real campers, real groups, and real money. That was another important shift because there are things people don’t think to mention when you ask them to describe their jobs. Camp staff aren’t walking around mentally cataloging every exception, workaround, and unusual situation they encounter. Many of those details only become visible when someone actually tries to do the work inside a system.

Sometimes a Snack Isn’t Just a Snack

Alan uses snacks as a great example of how quickly seemingly simple camp operations become complicated. You might assume a software system only needs to know that a group has requested a snack, but then the questions begin. Does the snack count as a meal? Is the kitchen responsible for it? What if the “snack” is s’mores at a bonfire and the maintenance crew is responsible for setting everything up? What happens when a camp has multiple dining spaces, or when the dining room isn’t large enough to accommodate all the groups on property at the same time?

None of those situations sounds particularly unusual to someone who works at camp. That’s precisely the problem. They aren’t necessarily rare edge cases—they’re just the normal ways different camps operate. Once real camps began using the software, those details exposed places where the original architecture needed to grow.

Alan describes version one as the attempt to take the enormous amount of information they had gathered and turn it into something simple and intuitive. Real-world use then revealed things they hadn’t accounted for, and eventually the foundational coding underneath version one wasn’t enough to handle everything camps were asking the system to do. Version two expanded that foundation, and continued testing helped the team work through more of the specific details. By the time this episode was recorded, they had recently launched version three, bringing together what they had learned over roughly three years of building, testing, and listening.

The feedback process hasn’t stopped. Camps can submit feature requests inside the system, discuss those ideas, and vote on them. Alan says it has been interesting to watch those requests change. Earlier feedback involved major operational needs, such as distinguishing day camp from overnight camp or accommodating a guest group within a traditional summer program. More recently, requests have gotten down to things like additional activity icons or more branding options for the camper portal. For the team, getting to those smaller requests has been an encouraging sign that many of the larger operational problems are finally being addressed.

Why One-Size-Fits-All Software Struggles at Camp

As Carl listened to the team describe that process, he connected it to his own experience changing accounting software. The new software worked, but it required him to change some of the ways he handled bookkeeping because the system expected the process to happen a particular way. That was frustrating, but there was an important difference: Carl was the only person doing the bookkeeping. He could learn the new process, adjust, and move forward.

At camp, that same problem spreads across an entire organization. Meals, lodging, activities, meeting rooms, guest groups, programs, snacks, maintenance, housekeeping, and sales all interact, and each camp has developed its own ways of making those pieces work together. One camp doesn’t offer snacks at all. Another provides them. Another allows groups to bring their own or order through the camp. Those camps might look similar from the outside, but operationally they aren’t the same.

That’s why simply asking camps which features they want can miss the larger issue. Alan explains that when a department requests a particular feature, his team tries to understand the purpose behind it. If maintenance says they need a certain checkbox, the real question is: What are you trying to accomplish with that checkbox? Where is the checkered flag? Once the team understands the desired outcome, they can think about how to support it without necessarily forcing every camp into that exact workflow.

That distinction gets to the heart of the episode. Camps have spent years adapting their work to systems that were never quite designed for the way they operate. The alternative is to start with the camp itself—how its people work, how its departments interact, and how it serves guests—and build the technology around that reality.

Camp technology should work like camp works.

Guest Group Registration Shows What Fragmentation Costs

One of the clearest places to see the limitations of disconnected camp systems is guest group registration. Many camps have registration software that works reasonably well for traditional summer programs, but guest groups operate differently. A church may already have its own registration process for the retreat, while the camp separately needs participant information, waivers, payments, rooming details, and other records. That can leave the group leader caught between two systems, entering or collecting the same information more than once.

Lindy had seen how frustrating that could become while working with a camp in New England. The camp required guest groups to use the same registration system it used for summer camp so that it could collect participant information and signed waivers. But the process was cumbersome enough that some group leaders told her they wouldn’t come back the following year if they had to use it again. In one instance, a youth pastor called Lindy because his wife had been helping with registration and had become so frustrated with the process that she was crying.

That experience became a significant driver behind how the team approached guest group registration. Instead of treating the group as an awkward addition to a system designed for individual summer campers, they wanted the group leader, participants, and camp to be working from a connected process. Lindy explains that a group can use the system to register participants, collect payments, manage waivers and electronic documents, create its own forms, and communicate with its people. At the same time, the camp has visibility into the information it needs to serve the group. The group leader can use as much of that functionality as makes sense rather than being forced into one rigid process.

Alan had experienced the fragmentation from the parent side as well. When he registered his son for camp in Southern California, he remembers having to move between multiple places to handle pictures, payments, the camper wallet, contracts, and other pieces of the process. Each individual tool may have had a purpose, but to the parent, none of those things felt like separate departments. They were all simply part of registering a child for camp.

That led Mark to ask a practical question during the conversation: Could the same idea work for a church renting a camp? Instead of the church maintaining one registration system while the camp asks everyone to go through another, could the camp provide a registration experience that handles the information, payments, forms, and rooming the group needs? Lindy’s answer was yes, and she emphasized that the group can choose how much of that process it wants the system to handle.

The larger lesson is that registration isn’t just an administrative process happening behind the scenes. For a camper, parent, youth pastor, or retreat leader, registration is part of the experience of doing business with your camp. When that experience requires bouncing among disconnected systems or duplicating work, the operational problem becomes a guest-experience problem too.

Knowing Who Is Actually on Your Property

Guest group registration also led the conversation into a more serious issue: knowing who is actually at camp. With some traditional guest-group processes, the camp may know that the group leader said 230 people were coming, but that doesn’t necessarily mean the camp has an accurate participant-level picture of who arrived or where everyone is staying. Lindy points out that a headcount from the group leader isn’t always the same thing as having reliable registration information for the people physically on the property.

MJ connects that concern to emergency preparedness. The conversation references the devastating flooding at Camp Mystic and asks what would happen if a camp suddenly needed accurate information about the people staying in a particular area or cabin. The point wasn’t to compare situations or suggest that software could prevent a disaster. It was to highlight a basic operational responsibility: in an emergency, camps need reliable information about the people in their care.

That concern had become particularly important for Forest Glen, one of the camps working with the team. As MJ describes it, the camp recognized that its previous systems did not give staff the kind of accurate, current picture of who was on property that they wanted. Guest-group registration therefore wasn’t simply about convenience or eliminating duplicate data entry. It was also about giving the camp and the group leader a clearer shared picture of who was actually there.

A Calendar Should Connect to the Work

Forest Glen also provided another example of how disconnected information affects day-to-day operations. The camp has two sides of its property, and Lindy explains that staff were maintaining two large whiteboard calendars manually because their previous software couldn’t integrate the calendars in the way they needed. They wanted one place where they could see what was happening across both sides of camp, along with housing, meeting rooms, activities, and availability.

But putting two whiteboards onto one digital screen only solves part of the problem. A group appearing on the calendar creates work for people all over the property. If 150 guests are arriving, housekeeping needs to know where they’re staying. The kitchen needs to know when they’re eating and how many people to expect. Maintenance may need to set up a meeting room. Activity staff need to know when to prepare equipment. Sales needs to understand what spaces are already committed before promising something to the next group.

That is where the Five C’s begin to connect. The contract and booking create information that affects the calendar, but the calendar then needs to help coordinate what happens after the sale. The value isn’t simply that everyone can see a date on a screen. It’s that the people responsible for serving that group can see the information that tells them what needs to happen next.

Carl points out that many camps already have software that does a decent job getting something booked. The breakdown often comes after that. When the kitchen needs to know who is coming to lunch or maintenance needs to know how a meeting room should be arranged, the system suddenly becomes a stack of printouts on a bulletin board, handwritten notes on a clipboard, or information passed from person to person. The booking may be digital, but the actual work of delivering the experience is still being coordinated manually.

From Digital Duct Tape to Connected Camp Operations

Moving away from those familiar processes does require some adjustment. Lindy says she’s worked with camp staff who initially look at entering an itinerary or complete schedule into the system and see additional work. If they didn’t have to enter all those details before, why should they start now? Her answer is that camps can continue doing what they’ve always done—handing out printed papers, relying on word of mouth, and communicating changes over walkie-talkies—but those methods require people to keep passing the same information around.

Entering the information properly on the front end may take more effort, but once it’s there, multiple departments can work from it. The person preparing the zip line can know when the group is arriving. The person saddling horses can see when the activity is scheduled. The kitchen can see meal counts. Instead of one person possessing the information and then repeatedly distributing it, the information becomes available to the people responsible for acting on it.

Lindy illustrates that idea with a much smaller example. Suppose housekeeping is working in cabin three and discovers an overflowing toilet. Instead of leaving the cabin to find someone, making a call, writing a note, or hoping the message gets passed to maintenance, the staff member can use a phone to create a maintenance request and even attach a photo. The task goes directly to maintenance, where the people responsible for fixing the problem can see it.

The technology doesn’t need to be complicated for the employee using it, either. Lindy explains that a maintenance staff member can have access to the part of the system relevant to maintenance without having to navigate everything happening in sales, registration, contracts, or other departments. That’s especially important at camps where some staff members may be hesitant about adopting another technology platform. A connected system may be doing a great deal underneath the surface, but each employee only needs the information and tools relevant to the work in front of them.

For Alan, that gets back to the reason for connecting all of these systems in the first place. The goal isn’t to give camp staff more software to manage. It’s to reduce the amount of time they spend sitting at a desk moving information around so they can return their attention to the people they’re there to serve.

“Get staff out from behind the desk and out doing mission.” — Alan Brown

That may be the most important measure of whether camp technology is actually working. The best system isn’t necessarily the one with the longest feature list. It’s the one that quietly helps the organization communicate and coordinate well enough that staff can spend less energy holding the operation together and more energy doing the work that brought them to camp in the first place.

Building the App While Being Shaped by the Process

Late in the conversation, Mark shifts away from features and workflows and asks a different kind of question. Building something that already exists is one thing. You can study the market, look at what other companies have done, and follow a reasonably established path. But MJ, Alan, and Lindy have spent the last several years trying to build something they believe doesn’t really exist in this form. Mark wants to know what has kept them going when the hill seemed especially steep.

For MJ, the answer is closely connected to his faith. He describes the experience as completely repackaging his relationship with God because there have been so many moments when the team couldn’t see how the next step was going to happen. There wasn’t a reliable formula they could follow or a predictable timeline that told them when everything would come together. Again and again, MJ found himself reaching a point where his only conclusion was, God has to come through. He says that kind of uncertainty changed his prayer life to the point where he feels like he’s “never not praying.”

Alan describes the same three years from another angle. There have been sleepless nights, frustrations, technical problems, and plenty of moments when the work felt overwhelming. But when Mark asks what has sustained him, Alan talks about the people around him. His wife and kids have supported him through the process, and so has a Christian camping community that didn’t simply behave like a group of prospective customers. Camps prayed for the team, encouraged them, tested what they were building, sent detailed feedback, and told them to keep going.

That support became tangible in different ways. Alan mentions camps such as Twin Peaks, Forest Glen, and Canyon View sending encouragement and feedback. Bearpaw went even further and invested in the project after recognizing that it had already been thinking about paying someone to build something similar. Alan remembers one camp director asking him, “How’s the spiritual warfare going?” It was a funny question, but it also reflected the way people around them understood the project. For the team, this wasn’t only a software startup. They were trying to build something they hoped would serve ministries they cared deeply about.

There were also repeated moments when provision seemed to arrive at exactly the point they needed it—even if it wasn’t on the timeline they would have chosen. Alan jokes that God apparently doesn’t use their timeline, but looking back, he can see a series of moments when they didn’t know how they would make it through the next stretch and somehow did. Mark listens to MJ and Alan describe those years and summarizes the journey well: while they were building an app, God was also shaping them as people.

Lindy’s Three-Year Roller Coaster

Lindy describes the same period as a roller coaster. There have been exciting moments when she could see the pieces coming together and discouraging moments when something still didn’t work the way she believed camps needed it to. Because she was spending so much time talking with camp leaders and testing the system against their real-world needs, she often became the person coming back to the team with another list of things that needed attention.

She also knows herself well enough to admit that she can be picky and perfectionistic. That made her a useful person to have testing the product, but it also meant MJ and Alan were constantly waiting for the day when she would finally say, This is ready. Over time, that became a running joke within the team. They wanted Lindy to wave the checkered flag.

And for three years, she didn’t.

The Checkered Flag

Then, in the middle of the podcast, Lindy surprises everyone. She reaches off camera and pulls out an actual checkered flag—something she had ordered from China about a year earlier and kept waiting for the right moment to use. MJ and Alan immediately realize what it means. For listeners who can’t see what’s happening, Mark stops to narrate the moment: after years of asking Lindy when she would finally wave the flag, she is literally holding it up during the interview.

Lindy is careful about what she’s saying. She isn’t claiming the product is finished forever. There will always be improvements to make, small things to adjust, and new ideas that come from camps using the system. The listening process that shaped the product isn’t supposed to stop simply because version three has launched. But after years of camp visits, roughly 60 conversations, beta testing, real-world use, multiple versions, and a lot of back-and-forth with the development team, she believes they have reached an important milestone.

“I think we’re there,” she tells them.

The reaction from MJ and Alan makes it clear that this is more than a product announcement. They have been waiting for Lindy—the person who kept testing what they built against what camps actually said they needed—to believe they had crossed that line. Her checkered flag represents the culmination of a process that started not with a predetermined list of features, but with a decision to keep listening until the system could handle the realities they were hearing about from camp leaders.

There’s also something fitting about the fact that the flag doesn’t mean the work is over. In Alan’s own approach to development, he often asks people to define the “checkered flag”—the outcome they’re really trying to accomplish rather than the particular feature they think they need. Here, the team has reached one of its own checkered flags. The product can move forward, even while the process of listening, improving, and adapting continues.

What This Means for Your Camp

As the interview winds down, Carl brings the conversation back to the camp leaders listening. Many of them know exactly what it feels like to have information living in five, six, or ten different places. They know the frustration of entering the same information twice, maintaining spreadsheets because the primary system can’t handle something, or relying on a particular staff member who happens to know how all the pieces fit together. What Carl appreciates about the story is that MJ, Alan, and Lindy aren’t approaching those frustrations as outsiders telling camps how they ought to work. Their process has been built around asking camps what they actually need.

That matters for sustainable growth because growth doesn’t stop when marketing succeeds. Every new camper or retreat group eventually reaches the operational side of the organization. Someone has to communicate with them, register them, collect the right information, house them, feed them, schedule their activities, prepare their meeting spaces, and make sure the staff serving them know what is happening. If every new guest also creates more duplicate work, more spreadsheets, and more manual communication, growth can put increasing pressure on an already stretched team.

The larger takeaway from the episode isn’t that every camp needs more technology. It’s that the technology a camp does use should support the way the organization serves people rather than becoming another obstacle staff have to manage. That’s why Alan’s line about getting staff “out from behind the desk and out doing mission” lands so well. Operational efficiency isn’t the end goal. The goal is creating more capacity for the work camp exists to do.

Mark closes the episode by recognizing that mission directly. Camp leaders are serving a generation surrounded by screens, anxiety, and constant digital connection, and camp gives young people an opportunity to connect differently—with God, with other people, and with experiences that can shape their lives. If better systems can give camp staff more time and attention for that work, then the technology is serving its proper role.

For camps interested in seeing what MJ, Alan, and Lindy have built, The One App is available at theoneapp.camp, where camp leaders can learn more and schedule a demo. The Grow Your Camp Podcast team is also asking listeners for feedback through the “Don’t make us guess. Tell us.” section of the podcast website. Camp leaders can suggest future topics or guests, share something that’s working at their camp, or tell Carl and Mark how the podcast could be more useful. As announced in the episode, the first five camps to respond will receive a $500 donation that can be used for scholarships, a capital campaign, or another camp need.

And as camps begin looking ahead to their 2027 marketing budgets, Carl and Mark also invite leaders who want help identifying growth opportunities to connect with them about a Growth Action Plan. Because getting more people to camp and having the operational capacity to serve them well have to work together. As Mark often puts it, you can’t minister to empty beds—but filling those beds sustainably also means building systems capable of supporting the ministry as it grows.

Let’s grow camp together.