Group Formation
A system that forms small groups instead of listing them. Rounds, constraints, explainable placement, pairs and households, backfill, and the delivery layer that tells everybody.
The product
The console, running.
A leader configures a program, opens a round, keeps the roster, forms, reviews, approves, publishes, and fills the seats that open mid-season, all without touching a terminal. Every panel below is the real behavior with invented people. Click things.
Two people open this.
Neither of them is you.
A leader’s real question is never whether the software works. It is what their people will experience, and whether they will be embarrassed by it. So both answers are here, before any feature: the same season, from the side that runs it and the side that lives in it.
- 1You answer five questionsWhere you are, how far you will travel, and the evenings you are actually free. Three to five minutes, once.
- 2You are told a date, not “soon”Enrollment closes on the 3rd. Groups form after it. You can see exactly where in that you are standing.
- 3A person approved your groupNever automatic. A leader looked at it, and your page says so, because that is the part that makes it worth trusting.
- 4You meet six peopleNames and faces, a first gathering, and one person you check in with each week.
Member · your round
You’re in the pool.
142people have joined
Oct 3enrollment closes
6to a group
A roster is not a directory. It is an input.
Everything the engine can use is a column here, and every column is a constraint an organization decides the weight of. Geography and availability are hard almost everywhere. Life stage is the primary cohesion axis. A household is one assignable unit, not two rows.
Fig. 01 · the round’s poolConsole / People
| Member | Area · radius | Free | Life stage | Unit | Tenure |
|---|---|---|---|---|---|
| Tomi A. | Rogers Park · 20 min | Tue, Thu | Young family | Household of 2 | Returning |
| Maya R. | Edgewater · 15 min | Tue | Young family | Individual | New |
| Kemi E. | Hyde Park · 25 min | Tue, Wed | Empty nest | Household of 2 | Returning |
| Ruth B. | Andersonville · 30 min | Thu | Newly married | Household of 2 | New |
| Nia P. | Woodlawn · 20 min | Tue | Single adult | Individual | New |
128 in the pool · 6 fields required before enrollmentA place that will not resolve blocks enrollment, on purpose
The system proposes.
A human approves.
Groups arrive with the sentences that justify them, because a placement nobody can explain is a placement nobody will defend. Select a member and every other group answers at once, will you take them, and why not, before anything is committed. Overriding is allowed; it is recorded.
Fig. 02 · proposed groups, with reasonsLive · click a member
proposedClick a member to see which groups will take them. Sara L. is flagged.
Group A4/5 · Tue
- TATomi A.Young family
- MRMaya R.Young family
- DCDele C.Young family
- JWJon W.Single adult
- Four are within 15 minutes of Rogers Park
- Tuesday evening is free for everyone
- One seat left, and the north side is thin
Group B4/4 · Tue
- KEKemi E.Empty nest
- SLSara L.Travel
- AOAyo O.Empty nest
- NPNia P.Single adult
- Three are clustered around Hyde Park
- Tuesday evening is free for everyone
- Sara L. is the exception, and it is flagged below
Group C3/5 · Thu
- RBRuth B.Newly married
- IGIfe G.Newly married
- HMHana M.Young family
- Thursday evening is the only night this set shares
- Two households, counted as units, not as four people
Fig. 03 · the move checkEvery destination evaluated before anything is committed
Four buttons is a trap. One is a decision.
A round moves open → closed → proposed → published, and each step is separately auditable. Showing all four at once invites doing them out of order. Showing the next one, with what it will and will not do and exactly who gets told, is the same information without the trap.
Fig. 04 · the lifecycleLive · advance the round
openclosedproposedpublished
Enrollment is open
128 people have joined. Members were told it closes on 3 October.
Closing stops new entries so the engine can solve against the whole pool. It emails nobody.
Fig. 04 · one next step, never fourNothing here has emailed anyone
Certainty beats speed.
It is the same wait either way.
A member sees four states in a season and never a list: not yet, in the pool, forming, and yours. The waiting screen is the one most products skip, and it is the one that decides whether somebody is still there in October. So it carries real dates, the size of the pool, and the promise that a person will check the group before anyone hears a word.
There are also two ways to step out, and the difference matters: leaving a group puts you back in the round; leaving the round takes you out of the season. Conflating them is how a system loses somebody who only meant to change rooms.
Fig. 05 · what happens nextMember · waiting
You’re in
Autumn 2025 · groups form after 3 October
- ✓You joinedYour answers are in the pool for this round.
- 2Enrollment closes · 3 OctoberWe wait for everyone so groups are formed against the whole pool, not half of it.
- 3Groups are formedMatched on where you are, your stage of life, and when you are free.
- 4A leader reviews themA person checks every group before anyone is told. Never automatic.
- 5You meet your group · 14 OctoberYou get names, and a first gathering.
128 people have joined so farPasswordless · no password to remember
The quiet failure is the expensive one.
Nothing in the notification layer moves on its own. If the schedule stops, there is no error and no alert, just members who were never told their group had formed. So the run takes a lease and leaves a record, pass or fail, and there is a health check that exits non-zero when the schedule has died.
Fig. 06 · one run, four jobs, in that ordertick.ts --health exits non-zero if the schedule has died
On your site, it is your product.
Ember, Archivo and the 14px people-radius are Family Dinner Foundation’s answers, not mbio’s. An organization running Groups inside its own site sets five variables and gets its own identity throughout: accent, tint, accent type, typeface, and the one radius. No component is re-styled and no stylesheet is forked, because a fork is a thing that silently stops receiving what we ship next.
Redeemer ChicagoSmall Groups · Autumn 2025proposed
Group A5/5 · Tue
- TATomi A.
- MRMaya R.
- DCDele C.
Group B4/4 · Tue
- KEKemi E.
- SLSara L.
- AOAyo O.
Fig. 07 · same markup, five variables#1F4E79 · 0px radius
A church with a serif wordmark and square corners throughout.
Four to six weeks, and nothing to rebuild.
You are not migrating a database. Groups is not a system of record and is not asking to become one. Your church management system keeps the people, a round takes a copy of the pool for one season, and what comes back is groups and the reasons for them. Nothing below is blocked on moving data. The dates are set by people answering questions, which is a different problem and a harder one.
01Scope90 minutesOne call. Your hard rules, your group size, the shape of a season, and which questions members will be asked.
02Stand up1–2 daysWe create your organization and your first leader account. That is a migration we run, not a signup form. There is no self-serve tenant yet.
03ConfigureHalf a daySizes, hard and soft rules, the profile questions, backfill mode, and the round's dates. A leader does it in the console; it is validated before it saves.
04Roster1–3 daysNames and emails into the roster, and a sign-in link to each. Typed, today: budget an hour per hundred people.
05Enrollment2–3 weeksMembers sign in and answer. The window is yours to set, and it is the one that slips.
06Form, publishOne afternoonClose, form, read the reasons, approve group by group, publish. The engine takes seconds. The reading is the hour that matters.
The phases above add up to about three weeks. Four to six is what it actually takes, and the difference is calendar rather than work: a launch lands on a Sunday, the leader configuring it has a day job, and an enrollment window is worth extending by a week when the answers are not in. We would rather quote the number you will hit.
Bringing your people in
Six ways an organization could get a roster into a round. All six now exist, which was not true when this page was first written. The two that every buyer asks about first, a file and a church-management connection, are the two most recently built. What each still costs you is next to it.
| Way in | What it costs you | State |
|---|---|---|
| A leader types the roster | Four fields a person (organization, first name, last name, email) in the console. About an hour per hundred people, and it is the only way a person gets on a roster today. | Built |
| A sign-in link to each person | One click. The email is queued and leaves on the next scheduled run, and there is no password for anybody to lose or for you to support. | Built |
| The member answers for themselves | Three to five minutes of theirs, and this is the part you cannot do on their behalf. Place, how far they will travel, when they are free, and anything else your program marks required. | Built |
| A CSV of the roster you already have | One export and a column mapping the console guesses for you. CSV, Excel, a zip, or a Google Sheet link. Nothing is written until you have seen what it would do, and the row that will fail tells you why before it fails. | Built |
| An application form on your own site | One link, and no typing. A form on your site posts each application to the console, and a person appears on the roster with their answers already on them: the location resolved to a real place, the evenings they chose turned into windows the engine can intersect. It will not guess: a city that could mean two places is recorded as unresolved and the member is asked. It also does not enroll anybody, on purpose. | Built |
| Planning Center or CCB, on a connection | Credentials once, sealed before they are stored, then people come across on demand. This removes the typing. It does not push formed groups back. That direction does not exist and has no date. A companion to a church management system rather than a replacement. | Built |
The long pole is profile completion
Even with an importer, and even with the Planning Center integration nobody has written, the schedule would not move much. A round needs two answers that no church management system holds: a place we can resolve to coordinates, and the times a person is actually free. An export gives you a name, an email, a household and a mailing address. It does not tell you that somebody will drive twenty minutes but not forty, or that Tuesday is the only evening that works.
Those two answers are the whole basis of the match, and they can only come from the member. So implementation is a response-rate problem wearing a software costume, and the number that decides your launch date is what share of your list answers an email in a fortnight. Plan the enrollment window around that, not around us.
Fig. 08 · what an export gives you, and what a round needsConsole / Profile requirements
| What the engine reads | Where it comes from | Source |
|---|---|---|
| Name | Any roster you already keep | In the export |
| Any roster you already keep | In the export | |
| Household | Usually in the export, occasionally as two rows | In the export |
| Life stage | Sometimes a tag; almost always worth confirming | Only the member |
| A place that resolves | Selected from Google Places, with coordinates. Free text is rejected. | Only the member |
| How far they will travel | Nobody's export holds this | Only the member |
| The evenings they are free | Nobody's export holds this | Only the member |
Enrollment is refused while a required answer is missingThe error names the fields, rather than saying no
What the product does about this is small, and worth stating exactly. The database refuses an enrollment with a gap in it and names the missing questions, so a half-answered person never degrades a group instead. The member’s own screen counts what is left. The roster shows answers per person, so a leader chases the eleven people who have not finished rather than emailing everybody. Nothing chases an unfinished profile automatically yet. The notification layer has the digests and the timers to do it, and no job is wired to fire them at an incomplete profile. That is the next thing we would build for a launching partner.
Keep the system you already run.
We are not trying to be it.
Groups does not want to be your church’s database. It wants the roster that database already holds, and it will take it from wherever that is, including the spreadsheet in somebody’s downloads folder, which is where it usually is.
ConnectionPlanning Center PeopleAn app ID and a secret, sealed before they are stored. People come across with the fields a round can use.
ConnectionChurch Community BuilderYour subdomain and a login. Both of CCB’s APIs are handled, because which one a church has depends on when they signed up.
LinkA Google SheetPaste the link. Re-reads on demand, so the sheet a volunteer keeps updating stays the source.
FileCSV, Excel, or a zipWhatever your office exports, including the one with three blank rows above the header and a comma in a surname.
Two things this deliberately does not do. It does not write back: formed groups do not appear in Planning Center or CCB, and there is no date we would stand behind for that. And an import never enrolls anybody. It puts people on the roster and answers what the source could honestly answer. Joining a round stays theirs to do, because two of the answers a round needs are ones no church management system holds.
Three capabilities. One engine underneath.
Built
Live
Mutual Care
Make it simple for people to ask for care and show up for one another. Members can request a meal, groceries, a ride, an errand, childcare, a check-in, or another act their community has offered.
Saved favorites and household details turn everyday care into a simple, one-click experience, while Honor recognizes the people who serve.
Explore Mutual Care ↗Shipped
Connection Matching
Real-time, activity-based social matching, already running as mbio. It is where somebody the round could not place goes the same day, instead of nowhere.
Mutual Care can live inside a formed group or across a larger community. Groups helps people belong. Mutual Care makes it easier for them to care for one another.
The parts, and what each is for.
| Part | What it does | State |
|---|---|---|
| The formation engine | Assignment and the validator for the policies it runs. Pure, zero-dependency, and it ships with no defaults of its own. | Built |
| Rounds | Loads a pool, runs the engine, persists, emits events. Backfill for seats that open mid-season lives here. | Built |
| Notification | Events in, queued messages out. Urgency, digests, timers, delivery with retries, and one scheduled tick that does all four. | Built |
| Sign-in | Passwordless. A link in an email, and no password for anybody to lose. | Built |
| The console | Program, round, roster, board, approval, publication, backfill. A whole season without a terminal. | Built |
| The member app | Profile, waiting, your group, and the two different ways to step out. | Built |
| Row level security | Every policy written against the platform's own identity claim, and both apps refuse to start in production on a connection those policies do not apply to. | Built |
| Mutual Care | Simple requests, saved care preferences, community offers, and one-click ways to show up for someone. | Built |
Run one round
See it form your people.
Bring one season’s worth of names and your hard rules. We will run the round with you, show you every placement and every reason, and you decide whether to publish it.