What 20 years in the trenches taught us about software

I've been doing church work for twenty years. The kind of church work where you arrive at 6am Sunday, set up sound, run the slides for first service, fix the projector between services, run a Sunday school class, and stay after to talk a sixteen-year-old through a hard week.

Most of the software the church world sells you was not built by anyone who's done that.

You can usually tell within five minutes. The vocabulary is off. The workflow doesn't match how anything actually happens on the ground. The feature that should be three clicks is fourteen, and the feature you'd never use sits front and center on every dashboard.

That's not the software's fault. It's a downstream problem of who built it. SaaS founders build software that looks great in a demo to other SaaS founders. Investors fund it. Procurement teams at large churches buy it. Then it lands on the desk of a part-time ministry assistant at a 200-person church and she spends Tuesday afternoon trying to figure out why she can't schedule a substitute teacher without paying for the next tier up.

When ministry leaders build software, the reflexes are different.

We know what 8am Sunday feels like. We know that "rotation" doesn't need to be defined. We know that a volunteer who can't make Tuesday's training isn't a flaky volunteer — she's a mom whose kid had a fever. We know that the pastor isn't going to log in three times this week to update the dashboard, and we know that's fine, because the dashboard was never the point.

We cut features that look good in a demo but fail in production. We say no to integrations that would broaden the addressable market but dilute the experience. We charge per church, not per user, because we want every volunteer onboarded — that's the whole point.

We make peace with being smaller as long as we get to be right.

This is what Cedar & Stone is. Software for churches that teach the Bible, built by the people who do the work. Not because doing the work makes the code any better — it doesn't, the code is the code. Because doing the work makes the decisions better. We're not optimizing for the next funding round. We're optimizing for the volunteer at the back of the room who's trying to figure out how to load the camera preset before the band starts playing.

That's where this all comes from. That's why we built it. That's who it's for.