Radius

The challenge

Valley Creek Church exists to be a movement of hope for the city and beyond. That’s the vision, stated plainly, and it’s a useful thing to hold onto when you’re building software for a church — because a movement is not a program, and it doesn’t get carried by a building or a service time. It gets carried by people.

Most of what that looks like doesn’t happen on a Sunday morning. It happens the rest of the week, in small groups the church calls circles — hundreds of them, meeting in living rooms and coffee shops, each one led by someone on a serve team who also has a job, a family, and a group of people counting on them. The staff who oversee all of that aren’t running a program either. They’re shepherding the shepherds.

The church ran that ministry on Church Community Builder. CCB is a capable system of record: it holds the people, the groups, the attendance, the history. What it isn’t built for is the job the staff actually has on a Tuesday — knowing where things stand right now. Which circles met this week. Which ones haven’t met in a month. Which leader has gone quiet. Who needs a phone call before Sunday.

So that gap got filled the way these gaps always get filled: exports, a spreadsheet that’s out of date by Wednesday, group texts, and somebody’s memory. The information existed the whole time. It just never arrived anywhere near the moment a person could act on it — and a report that tells you a circle has stopped meeting is telling you about weeks that have already gone by.

That is not a problem you solve with another report. The data was fine. What was missing was a tool shaped like the work — and no product on the market is shaped like one church’s ministry, because no product on the market was built for one church.

The approach

A name and a brand, before a single screen

Internal tools get treated as furniture, and staff use them the way people use furniture — grudgingly, and only when there’s no way around it. We didn’t want that. So the first deliverable wasn’t a wireframe, it was a name.

Radius: the reach of a circle. It comes straight out of the church’s own vocabulary, and it says what the tool is for — not counting circles, but extending how far each one reaches. From there we designed the whole identity in-house: the mark, the palette, the dark interface it lives in, the type, the way a status or a label reads at a glance. The result is a product that feels made rather than assembled, which is most of why people open it on a Tuesday without being asked.

Built on their data, not beside it

The fastest way to kill an internal tool is to make it a second place to type things that are already typed somewhere else. Radius integrates directly with the Church Community Builder API, so the people, the circles, the meetings, and the attendance come from the church’s existing system of record. CCB stays the source of truth. Nobody re-keys anything, and there is never a question of which copy is right.

What CCB was never going to hold — the shepherding layer — lives in a Supabase database whose structure we designed for this work specifically: leader relationships and the history behind them, follow-ups, notes, tasks, review states, onboarding progress, everything staff know about a circle that isn’t attendance. Their record system keeps doing its job. The new information finally has a home instead of living in an inbox.

Reporting people actually open

Every church platform has reports. The reason nobody reads them is that they answer questions in the aggregate, weeks late, in a format built for a board packet. Radius reports in real time and in the direction the work runs: total attendance, circles meeting, average circle size, compliance, the ones that didn’t meet, the ones that never turned in a summary — each shown against the prior week so the number carries a direction, not just a value.

From there it moves both ways. Zoom out for the whole church across a season and the trend lines say whether the ministry is growing or quietly shrinking. Zoom in to a single circle and it’s one leader, one group, one pattern of weeks. The point of the dashboard isn’t to be comprehensive — comprehensive is what made the old reports useless. It’s to make the thing that needs attention the thing you see first.

A board where the cards are people

Ministry work doesn’t arrive as a tidy list. It arrives as a hundred half-finished threads: a leader to call back, a new host to get set up, a circle to check in on, a conversation to finish. So Radius includes a Trello-style kanban board — but the cards on it are as often a person as a task. Columns for how you actually work, labels and priorities, due dates, a today view that pulls what’s due to the front, and keyboard shortcuts for the staff who live in it all day.

It sounds mundane next to the integration work. It’s the feature that keeps people from falling through, which makes it the one that matters most.

Relationships that survive a staffing change

The knowledge that makes a ministry work is usually undocumented: who’s carrying something heavy right now, who’s ready to lead, who hasn’t been called since February. It lives in one staff member’s head, and it leaves when they do.

Radius keeps the relationship history with every circle leader in one place — the interactions, the notes, the follow-ups, what was said and when. Not to score anyone. So that a leader is known by the church rather than by whichever staff member happened to have their number, and so that the next person to pick up the relationship starts where the last one left off.

Onboarding that doesn’t lose people at the door

The most expensive moment in any ministry that runs on serve teams is the gap between “I’d like to help” and actually being set up to do it. Every week in that gap costs you people. Radius carries the intake for new leaders and new members, so bringing someone on is a path with a visible state rather than a step somebody has to remember to take.

Communication that arrives like a text, because it is one

Email to a serve team is a slow way to be ignored. Radius lets staff send messages to large groups of people through an iMessage integration, so a note about Sunday lands in the app people already answer, from a number they recognize — not as a broadcast from a marketing platform that gets swiped away with the rest of them.

AI that reads the week so a person doesn’t have to

Hundreds of circles filing summaries every week produces more written material than any staff member can honestly read. Most of it is ordinary and a little of it matters urgently, and the only way to find the little was to read all of it.

So Radius reads it. AI summarizes and analyzes what comes in across circles — what happened this week, what’s trending, where something is worth a second look — and hands staff a short read instead of a pile. It doesn’t make decisions and it isn’t pretending to be a pastor. It does the reading, so the pastoring goes to the people who need it.

A progressive web app, so it’s on the phone without an app store

This work happens standing in a church lobby, in a car before a meeting, on a couch on Sunday night. It also happens at a desk with fifteen tabs open. Radius is built in Next.js as a progressive web app, which means one build covers all of it: full desktop, genuinely usable on a phone, and installable straight to a home screen where it opens like any other app — no app store, no review queue, no separate mobile codebase to maintain in parallel.

Access is role-based, so what someone sees matches what they’re responsible for. A tool holding real information about real people in a congregation has to be careful about who sees what, and that has to be true by design rather than by policy.

The whole stack, and someone to carry it

Next.js for the application. Supabase for the database, with a schema we designed around this ministry rather than adapted from a template. Netlify for deploys, so a fix ships in minutes. GitHub for the source, so there’s a real history and nothing about this build depends on a laptop.

We built every piece of it and we run every piece of it. No church staff should need an engineering department to keep its own software alive — when something needs to change, they send a message, the same way they would about a website, a brochure, or anything else we look after.

The outcome

Valley Creek Church has a platform of its own. Staff open one place and see the state of the whole ministry — what met, what didn’t, who’s thriving, who’s gone quiet — on a phone in a lobby or a laptop at a desk, current as of right now instead of as of last Monday’s export. The follow-ups live on a board instead of in someone’s memory. The relationship history stays with the church. The week’s reading gets summarized before anyone has to sit down with it. And CCB keeps doing exactly what it’s good at underneath all of it.

What that buys isn’t efficiency, or not mainly. It’s attention pointed at the right place. The gap Radius closed was between knowing something and being able to act on it, and closing it means a leader who’s struggling gets a call this week rather than next quarter.

Which is the entire reason the software exists. Valley Creek isn’t trying to run tidier small groups for their own sake — they’re trying to be a movement of hope for the city and beyond, and a movement travels exactly as far as its leaders are known, supported, and built up. Radius is our part in that. Not the ministry, but the tool that lets the people doing the ministry see clearly and move fast, and that keeps a circle leader from being a name in a report instead of a person somebody called on Tuesday. Getting to build something for a vision that size is not ordinary work, and we don’t treat it as ordinary.

It’s also the clearest answer we have to the question of what this studio can build. Radius is not a website with a login on it. It’s a name, a brand, a product, a database schema, an integration with someone else’s API, a real-time reporting layer, an AI layer, and an installable app — designed and built by the same two people, on one stack, with no hand-offs and nobody to blame but us. That’s the whole idea: one team, whole journey.