About

Church knowledge shouldn't live in silos.

Greenroom is a knowledge base built for church staff and volunteers together. What one ministry works out, the next one can find. What a staff member writes on a Tuesday, a volunteer can read on a Sunday. One source, and no retelling it in a hallway.

Where it came from

Two vantage points on the same problem.

One from the staff member trying to hold it all together. One from the volunteer standing in a dark room on a Sunday morning.

Greenroom started with the worship operations team at NewSpring Church in Anderson, South Carolina. The director who runs it needed a way to aggregate what his team knew and get it in front of the people serving — across services, across campuses, and across a volunteer roster that turns over constantly. He is also my brother-in-law, which is how the conversation started, though it is not why the product exists.

What he had wasn't a knowledge problem. These were capable people running a complex weekly operation well. The knowledge existed — in a Drive folder, in a binder, in one case taped to the back of an amp rack. It just had no single place to live, no way to tell which version was current, and no way for a volunteer to reach it on a Sunday morning.

The walls ran sideways too. One ministry had already worked out a problem the team down the hall was still solving from scratch, and neither had any way of knowing that.

So the same forty minutes of explanation happened out loud, in a hallway, over and over.

The explanation had nowhere to live.

The second vantage point is mine. I have attended the same church for twenty-five years and served on the production team for a good stretch of that, and in all that time nobody ever handed me anything like this. Not because anyone was careless — because there was nowhere to put it.

I kept hitting the same wall from the volunteer side: knowing there was a right way to do something, not knowing where it was written down, and not wanting to pull someone out of a service to ask. That's the half of this problem most software never sees, because the people building it have never been the volunteer.

He had tried to buy his way out of it. The tools that came closest were built for corporate training, which meant modules, completion tracking, and an account for every volunteer. Each of those triggered an IT review and a data conversation that belonged to an entirely different department, and the purchase never happened.

That gave us the shape of the product before a line of it was written. It had to be a reference site rather than a course. Anything put in front of a volunteer had to open without an account and hold no information about whoever opened it, which is both the right thing to do and the reason nobody has to approve it. And it had to be maintainable by someone whose actual job is not maintaining it.

The name comes from the room where a team gets ready before they go out and do the thing. That is where most of the work of a Sunday actually happens.

How we build

Three commitments.

Published so you can hold me to them, and so you know what to expect when you request a feature and the answer is no.

  • Small on purpose. Every feature added is another thing a volunteer coordinator has to understand at 8:40 on a Sunday. Most requests are better answered with a no, and I'll tell you which ones and why.
  • Nothing collected on volunteers. Staff have logins, and staff checklists keep a record, because sometimes you need one. Volunteers never create an account, so there is nothing there to collect — no analytics, no engagement scoring, no read receipts, nothing to breach. That removes a category of risk from your building, and it removes the temptation to build the wrong product. A tool that measures volunteers becomes a tool that manages volunteers, and that is a different company than the one I want to run.
  • Straight answers, including on sales calls. If another tool is the better fit for what you have described, I'll say so and name it. Churches talk to each other, and being trusted is worth more than being busy.
The company

Allie Technologies.

A micro-SaaS company in Greenville, South Carolina. We build a small number of focused products and keep each one narrow rather than growing any of them into a platform. Greenroom is the one built for churches.

The name is meant literally. Allie is an ally — software that takes one specific job off your hands and doesn't ask you to reorganize around it.

Grant Reeves is the founder. He writes the code, and he answers the support email.

Where things stand

Greenroom is early, and I'd rather say so than let you find out. It was built for one church, and right now the operations director there is the one putting it through real Sundays. You would be among the first churches on it.

That's worth knowing before you decide, and it cuts both ways. There is no long list of references to call. There is also nobody ahead of you in the queue: the roadmap is genuinely set by whoever is using it, and the things that get in your way are the things that get fixed.

The person answering your email is the person who wrote the feature you're asking about. That's an advantage now and it won't scale forever, so it's worth using while it lasts.

Ask me something directly

Worth twenty minutes?

No deck. I'll open your own documents in it and you can tell me whether it helps.