Why it matters
Good software needs a good church to test it on.
Every screen in Rock is about people: who came, who gave, who serves, who needs prayer. You can't test those screens, teach them, or show them well with empty or random data. So we built a church.
The problem
The old sample data had four problems.
It was slow.
The old loader saved one record at a time through the full Rock model.
NowThe new loader loads the Cast into Rock in about 4 seconds, and 25,000 people in under a minute.
It was thin.
Connections, prayer, serving, and communications had little or no data.
NowEvery feature has history, from check-in streaks to giving alerts.
It wasn't realistic.
Random numbers hid bugs and made demos look fake.
NowPatterns come from summary-only queries on real churches, run with permission, and are graded every build.
It went stale.
Fixed dates fell out of "last 12 months" reports.
NowEvery date counts back from install day, so reports are always full.
Vision 1
A proving ground for testing and AI.
A test is only as good as the data under it. When data is random, a test can pass for the wrong reason. When a family's giving, attendance, and groups don't fit together, a bug can hide in plain sight.
AI raises the bar again. An assistant asked "who stopped giving this spring," "which kids missed check-in," or "who is ready to serve" needs answers that really exist in the data. Then we can judge whether it found them.
- Known people. The Cast is the same in every dataset, so a test can name Ted Decker by Guid and trust that he is there.
- Stories that hang together. A family's attendance, giving, groups, and serving fit together the way they do at a real church.
- Repeatable. The same seed builds the same church, so a failure can be reproduced.
- Big when you need it. Full 7 has about 25,000 people for performance and reporting tests.
- Proven against Rock. Every package is loaded into a clean Rock and checked by Rock's own cleanup job before it ships.
Vision 2
One church for teaching and showing Rock.
Rock is learned through help articles, screenshots, videos, and training classes. When each one uses different made-up people, learners have to start over every time.
With one shared church, they don't. They meet the Decker family in the first lesson and follow them through check-in, giving, groups, and serving. Ted Decker is already the face of most Rock documentation, and now his whole church is real enough to explore.
- Documentation. Every screenshot shows the same families, with full, believable history.
- Training classes. Each student installs the same church, so exercises work the same for everyone.
- Demos and promotion. Rock looks the way it does at a real church, not like an empty test site.
- A shared look. Rock Solid Church has a logo, a building, and photos anyone can use. Get the brand kit.
Vision 3
A resource the whole community can grow.
Everything about the church lives in plain data files: the families, their stories, the campuses, the service times. Anyone can read them, and anyone can suggest a change. This site is the front door for that work.
Who it's for
One church, many jobs.
Core developers
Load a realistic church in seconds, then build and debug against people you know by name.
QA and AI testing
Write tests and agent evaluations that name real Cast people and expect real answers.
Trainers and writers
Teach every class and write every help article with the same families and the same screens.
Demos and partners
Show Rock with a church that looks alive, from the dashboard to the last report.
Plugin developers
Test a plugin against the same data the core team uses, at the same size.
The community
Propose families and stories, and help the church cover more of Rock.
Store who people are. Generate what they did, counting back from install day.
The idea behind every dataset. How it's built