Associate Network · Parent-teacher organizations, booster clubs & community groups · Early access · 2026

The software the community already buys can fund the organizations that represent it — the associate model

Associate Network is the organization side of a model designed so that school community organizations — parent-teacher organizations, booster clubs, and community groups — become named fund beneficiaries. When a supporter subscribes to the community suite and selects your organization, a split of that subscription accrues to your community fund in an integer-cents ledger. The exact-cents split engine and the agreements engine that will paper every partnership are built and production-ready. The model is in active design; the payout rail is founder-gated. The model accrues a provable balance but pays nothing until the payout rail is founder-enabled and a real organization has been paid. Early access — no pricing commitment, no signup, no live payments today.

Book a conversation How it works

Exact-cents splitfee off gross first, largest-remainder reconciliation, platform residual disclosed as a counsel-set term

Agreements engineevery partnership papered through the existing tamper-evident engine — built

Provable balanceinteger-cents sub-ledger accrues per renewal — payout honest-off

Consent-gatedorganization data owned by the organization, never sold, no student reference in the fund ledger

The structural problem — and the structural fix

Your organization already represents the community. The associate model gives that representation a financial stake in what the community buys.

School community organizations have spent decades running wrapping paper sales, discount-card drives, and cashback programmes that route a fraction of a third party’s retail margin to the school fund. Those programs fight over thin margins and require families to remember a separate URL or opt into a separate app. The structure is designed around the retailer’s acquisition cost tolerance, not around what is actually meaningful for a school.

The associate model is a different construction. Our marginal cost to serve one more seat of software we already built is approximately zero — the substrate is shared across the whole platform fleet. That means the split we can publish is set by our own economics, not by a third party’s retail margin. A supporter subscribes to genuinely useful software they would plausibly buy for their own work, selects your organization as their named beneficiary at the same checkout, and a split accrues to your community fund on every renewal. No separate URL. No second programme to remember. The software is the point; the split is a structural feature of how we priced it.

The exact-cents split engine and the agreements engine that will paper every associate partnership are built and production-ready. The model accrues a provable balance but pays nothing today — the payout rail is honest-off, present in the platform, not yet enabled for live disbursement. We say so directly. The goal is an honest description of what is built and what is coming, so that an organization making a decision about early access knows exactly what it is joining.

Book a conversation The platform

How it works

The organization’s journey in four stages

Associate Network runs on a four-stage model: becoming a fund-eligible associate, supporters selecting the organization as their beneficiary, the community fund accruing per renewal, and the organization seeing the balance in a transparent dashboard. Every stage is described honestly: built engines are built; honest-off items are honest-off.

Step 1 · Becoming an associate — participation agreement and fund eligibility

An organization applies to become an associate. A participation agreement is drawn up through the agreements engine — covering the split designation, payout consent, data-processing terms, and the organization’s right to withdraw at any time. Once the agreement is active and the organization is confirmed as fund-eligible, it appears in the beneficiary picker for supporters on the buyer side. The participation agreement is the written contract required before any accrual claim is made: one agreement per organization, held in the tamper-evident ledger. Live partner onboarding is honest-off while in active development; the first associates are onboarded through an early access conversation with no pricing commitment.

Step 2 · Supporter selection — a named beneficiary at the buyer’s checkout

When a supporter subscribes to the community suite on associate.software, they can select a named fund-eligible organization as their beneficiary. The selection is a typeahead picker: name, city, and state from the pool of fund-eligible organizations. Each subscription carries one named beneficiary at a time. The supporter can change their beneficiary between renewal cycles. The organization they select receives the split credit when the subscription renews — not a fraction of a third party’s retail margin, but a split of the platform’s own subscription price. The exact split rate is a legal disclosure set by counsel and the founder; the mechanism is as described here.

Step 3 · Fund accrual — one integer-cent credit per renewal

Each time a supporter’s subscription renews, the split instruction runs: fee off gross first, then the split is applied to the net remainder by the exact-cents engine, and an exact integer-cents credit is appended to the organization’s community fund sub-ledger. A largest-remainder reconciliation pass ensures the total is exact to the cent. The credit is dated and auditable. The model accrues a provable balance but pays nothing — the payout rail that would move the balance to the organization’s account is honest-off: present in the platform, not yet enabled for live disbursement. The organization’s balance grows with each renewal; no dollar moves until the founder enables the payout.

Step 4 · Fund transparency — the organization’s community fund view

The community fund dashboard shows the organization an aggregate integer-cents balance, a dated credit history by renewal event, and a supporter count. It shows a count only — never an individual supporter’s identity, name, or contact information. It never joins to any student row; the community fund view is entirely separate from any student data. The organization owns its fund records: the ledger history, the credit log, and the supporter count belong to the organization and are never sold or shared with outside parties. One-click export is available in writing — if the organization ever leaves, every credit record leaves with it.

The platform

Five engines — honest about what is built and what is coming

Every feature is labelled honestly: Built means the underlying engine is production-ready. In development means the surface, wire-up, or specific new kind is in active build. We do not claim otherwise.

The associate model — community organizations as named fund beneficiaries

An associate is a school community organization — a parent-teacher organization, a booster club, or a community group — that opts in to become a named fund beneficiary. When a supporter subscribes to the community suite on the buyer side and selects the organization, a split of that subscription accrues to the organization’s community fund in an integer-cents ledger. The model rides the same exact-cents split engine that runs the booster club fundraiser infrastructure — fee off gross first, split to the ledger, exact cents, with the platform’s residual and the organization’s split both disclosed as counsel-set terms before any partnership is papered. The model is in active design and the wire-up is being built. The payout rail — the part that moves money to the organization’s account — is honest-off: present in the platform, not yet enabled for live disbursement. The model accrues a provable balance but pays nothing until the payout rail is founder-enabled and a real organization has been paid end-to-end.

Model in active design · payout rail honest-off

The participation agreement — the paper that makes every partnership real

Every associate partnership is papered through the existing agreements engine — a purpose-built engine that handles draft, sent, signed, countersigned, active, and void states with a tamper-evident ledger and a single-path signing flow. The community participation agreement is a new kind in that engine: it covers the split designation, payout consent, data-processing terms, and the organization’s right to decline or withdraw at any time with no penalty. The agreements engine is built and production-ready. The community participation agreement kind and the live partner onboarding flow are honest-off — in active development, not yet live. The participation agreement also satisfies the written-contract requirement before any accrual claim is made: one agreement per beneficiary organization, held in the tamper-evident ledger, with the split disclosure in writing. The organization does not need to track that paper separately — the engine holds it.

Agreements engine built · partner onboarding honest-off

The exact-cents split engine — fee off gross first, largest-remainder reconciliation

The split engine divides gross proceeds with exact-cent precision. The fee is deducted from gross proceeds first — before any split is calculated — and the split is applied to the net remainder. A largest-remainder reconciliation pass ensures the distribution totals to the cent with every penny accounted for between the named legs and the platform’s residual. The platform keeps a residual on the net remainder; its exact rate, like the organization’s split, is a counsel-cleared disclosure set before any partnership is papered — the mechanism is transparent, not a hidden skim. A split instruction specifies the organization, the basis-point amount, and the effective date; the server resolves the integer-cents credit at each billing cycle and never trusts a caller’s value. The split engine is built and production-ready. The charge rail that moves money — the payout layer that would actually disburse the accrued balance to the organization’s account — is honest-off: present in the platform, not yet enabled for live transactions.

Split engine built · charge rail honest-off

The community fund ledger — append-only, integer cents, auditable

The community fund sub-ledger rides the platform’s integer-cents ledger substrate: an add-only-by-convention log with a unique posting key per event and per-node RLS isolation — the same idempotency pattern used across the platform’s commerce ledger (not yet hash-chained the way the parent-group and meal-account ledgers are). Each time a supporter’s subscription renews, a credit event is appended to the organization’s community fund sub-ledger — exact integer-cents, dated, and add-only by convention. The ledger has no student reference: it is a financial record for the organization, not a student record; there is no foreign key to any student row, enforced at the schema. The integer-cents ledger substrate is built and production-ready. The community fund sub-ledger — one per fund-eligible organization — is a thin new kind riding that substrate; the sub-ledger and the payout disbursement are honest-off while in active development.

Ledger substrate built · community sub-ledger honest-off

The community fund dashboard — aggregate balance, credit history, supporter count

The organization-side community fund dashboard shows three things: an aggregate integer-cents balance (the running total of all credited splits since the organization became an associate), a dated credit history (one row per supporter renewal, showing date and credited amount), and a supporter count (how many active subscribers have named the organization as their beneficiary). It shows a count only — never a supporter’s name, contact, or identity. The dashboard never joins to any student row; the community fund view is entirely separate from the school’s publication, recognition, or roster data. The organization owns its fund records. The dashboard is in active development. An organization in an early access conversation today will see the ledger structure and the dashboard in build; the full live view is not yet deployed.

Dashboard in active development · accrual honest-off

Who it is for

Built for the organizations that already represent a school’s community — parent-teacher organizations, booster clubs, and community groups

Parent-teacher organizations

A parent-teacher organization runs the school’s community calendar: the fall carnival, the book fair, the volunteer drive, the community fund. The associate model adds a channel that requires no event setup and no volunteer hours: supporters in the community subscribe to useful software and select the organization as their beneficiary. The community fund accrues per renewal, not per event. The organization’s treasurer sees an aggregate balance and a dated credit history in the dashboard. The organization does not need to promote the platform — promotion is opt-in and advertising-obligation-free.

Booster clubs

A booster club already has the game-night and show-night operational stack at schoolbooster.network: gate-scan, concessions point-of-sale, per-program treasury, and the exact-cents split engine for season fundraisers. The associate model is an additional channel: the same exact-cents split engine that powers the booster’s fundraiser also runs the community fund accrual for software the booster’s community buys. The two are separate surfaces on the same substrate. A booster club can use both: the operational platform for the season, the associate model as a recurring off-season funding channel.

School community groups and councils

A school community council, a fine arts booster, a student advisory group, or a school foundation can become an associate. The participation agreement is drawn up through the existing agreements engine — no custom workflow, no separate paper chase. The community fund sub-ledger accrues per renewal from the day the participation agreement goes active. The dashboard shows the aggregate balance, the credit history, and a supporter count — never individual identities. The organization owns its fund records outright and can export them at any time.

The participation agreement — a new kind in an existing engine

Every associate partnership is papered through the agreements engine. No custom workflow, no PDF chase.

The agreements engine already handles every kind of agreement on the platform: studio client agreements, consent agreements, e-sign documents, and platform terms — each with a tamper-evident ledger, a single-path signing flow, and a full draft-sent-signed-countersigned-active-void lifecycle. The community participation agreement is a new kind in that same engine, not a new system. An organization signs once; the engine holds the record.

The participation agreement covers four things: the split designation and the exact disclosed rate (set by counsel, stated in writing before signing); payout consent (the organization agrees to receive disbursements when the payout rail is enabled); data-processing terms (consistent with the organization’s existing privacy obligations); and the organization’s right to withdraw at any time with no penalty. The organization is not required to advertise, display branding, or run a promotional campaign. Participation is opt-in at every stage.

The participation agreement is also the written contract that satisfies the commercial co-venture requirement — the legal framework that applies when a for-profit company publishes that a purchase benefits an organization. By routing the agreement through the existing engine with the split disclosure in writing, the compliance record is held where the operational record already lives. The agreements engine is built and production-ready. The community participation agreement kind and the live onboarding flow are in active development.

Data & the firewall

The community fund ledger has no student reference. The organization’s data is never sold.

The community fund sub-ledger is a financial record for the organization, not a student record. By schema enforcement, there is no foreign key from any community fund record to any student row. A community tenant account type is never granted access to any student-data module — the SIS, the gradebook, the consent ledger, the yearbook engine, or any record involving minors’ data. These are structural boundaries, not policies. A misconfiguration cannot expose student data to a community account because the capability row granting that access does not exist for that account type.

The community fund dashboard shows the organization a supporter count, not supporter identities. An organization cannot see who its supporters are by name — it sees how many active subscribers have named it as their beneficiary, and the aggregate credits. Supporters are not required to identify themselves to the organization. The organization’s fund records — the credit ledger, the credit history, and the supporter count — belong to the organization and are never sold or shared with outside companies or advertisers.

Opt-in consent for community communications is required before any contact is added to any list. Consent is not assumed. It is collected. Consent can be withdrawn at any time. One-click export is available in writing — if the organization ever leaves the platform, every fund record leaves with it: the credit ledger, the credit history, and the supporter count.

What is built and what is coming — plainly

The engines are built. The payout rail is not live yet.

Built and production-ready today: the exact-cents split engine (fee-off-gross-first, largest-remainder reconciliation, exact-cent reconciliation to the net remainder); the agreements engine (draft-sent-signed-countersigned-active-void lifecycle, tamper-evident ledger, single-path signing); and the integer-cents ledger substrate (add-only by convention, unique posting key, RLS-isolated — the same idempotency pattern used across the platform).

In active development: the community participation agreement kind in the agreements engine; the community fund sub-ledger (one per fund-eligible organization, riding the built substrate); the community fund dashboard (aggregate balance, credit history, supporter count); and the live partner onboarding flow. The model is in active design.

Not yet enabled: the payout rail (Stripe Connect school-side KYC plus the ACH disbursement flag) is honest-off — present in the platform, not yet enabled for live disbursement. The model accrues a provable balance but pays nothing until the payout rail is founder-enabled and a real organization has been paid end-to-end. There is no live checkout, no billing, and no subscription on this page. We say so directly because a school community organization making a decision about early access deserves to know exactly what is production-ready and what is still being built.

Connected products

Associate Network is the organization side. associate.software is the buyer side. schoolbooster.network is the operational booster platform.

The community fundraising split model has two sides. associate.software is the buyer side: the community suite storefront where supporters subscribe and select a named beneficiary at checkout. Associate Network is where the named organizations live — the partner-agreement side, the fund dashboard, and the early access conversation for organizations. The two sites are the two ends of one loop; they cross-link each other.

schoolbooster.network is the operational booster club platform: gate-scan, concessions point-of-sale, per-program treasury, season-pass ticketing, and volunteer coordination. A booster club using the operational platform can also become an associate — the two surfaces run on the same substrate and can be used together. homeroom.software is the school publishing platform: the free digital yearbook, the newspaper, the literary magazine, and the consent infrastructure that runs the whole fleet.

associate.software schoolbooster.network homeroom.software

Early access · Parent-teacher organization officers, booster club treasurers, community group leaders

Book a conversation to see the current state honestly

Associate Network is in active design and build. We do conversations that show the current state honestly: how the agreements engine works for a community participation agreement, what the community fund sub-ledger looks like in build, how the split engine projects an exact-cents credit per renewal, and what the fund dashboard will show the organization. There is no pricing commitment and no signup. If it looks right for the organization, we discuss what a lighthouse associate partnership looks like before the payout rail is live.

To book: email [email protected].

FAQ

Common questions

What is the associate model, and which organizations does it fit?

The associate model is designed for school community organizations that already represent a school’s community: parent-teacher organizations, booster clubs, school community councils, and similar groups. An associate is a fund-eligible organization that a supporter on the buyer side can name as their beneficiary when subscribing to the community suite. A split of that subscription accrues to the organization’s community fund in an integer-cents ledger. The model is in active design; the payout rail is honest-off.

Is the payout live? Does the organization receive money today?

Not yet. The split engine, the integer-cents ledger substrate, and the agreements engine are built and production-ready. The payout rail — the layer that would actually move the accrued balance to the organization’s account — is honest-off: present in the platform, not yet enabled for live disbursement. The model accrues a provable balance but pays nothing until the payout rail is founder-enabled and a real organization has been paid end-to-end. There is no live checkout, no billing, and no subscription on this page. The CTA here is “book a conversation,” not “sign up and pay.”

How does the split engine work — what is the exact mechanism?

The split engine runs three steps at each billing cycle: (1) the platform fee is deducted from gross proceeds first, before any split is calculated; (2) the split is applied to the net remainder, using a basis-point instruction the server resolves to integer cents, never trusting a caller’s value; (3) a largest-remainder reconciliation pass ensures the credited legs plus the platform residual equal exactly the net remainder to the cent. The result is one integer-cents credit to the organization’s community fund sub-ledger per renewal; the platform keeps a residual on the net remainder whose exact rate is a counsel-cleared disclosure, not a hidden skim. The split engine is built and production-ready. The charge rail that moves money is honest-off.

What does the participation agreement cover, and how is it signed?

The participation agreement rides the existing agreements engine — a purpose-built engine with a tamper-evident ledger and a single-path signing flow. For an associate, the agreement covers: the split designation and the exact disclosed rate (set by counsel), payout consent, data-processing terms, and the organization’s right to withdraw at any time with no penalty. The agreements engine routes signing through a single link; no separate PDF workflow is required. The participation agreement is the written contract the commercial co-venture framework requires before any accrual claim is made. The agreements engine is built; the community participation agreement kind and the live onboarding flow are in active development.

What does the community fund dashboard actually show the organization?

The dashboard shows three things: (1) an aggregate integer-cents balance — the running total of all split credits since the organization became an associate; (2) a dated credit history — one row per supporter renewal, showing date and credited amount; (3) a supporter count — how many active subscribers currently have the organization as their named beneficiary. It shows a count only — never a supporter’s name, address, or identity. The dashboard never joins to any student row. The community fund view is entirely separate from the school’s yearbook, roster, or publication data. The dashboard is in active development.

Who owns the fund records? What is the data posture?

The organization owns its fund records outright — the credit ledger, the credit history, and the supporter count. None of that data is sold or shared with outside companies or advertisers. The community fund sub-ledger has no student reference: by schema enforcement, there is no foreign key from a community fund record to any student row. A community tenant account type is never granted access to any student-data module: the SIS, gradebook, consent ledger, yearbook engine, or any record involving minors’ data. These are structural boundaries. One-click export is available in writing: if the organization ever leaves, every credit record leaves with it.

How is Associate Network different from the booster club platform?

schoolbooster.network is the operational platform for booster clubs: gate-scan, concessions point-of-sale, per-program treasury, season-pass ticketing, and volunteer coordination — the game-night and show-night operational stack. Associate Network is the partner-agreement side of the community fundraising model: an organization opts in, a participation agreement is drawn up, and the organization becomes a named beneficiary that supporters on the buyer side can select. They are different surfaces on the same substrate. A booster club can use both: the booster platform for its operational season, and the associate model as an additional funding channel. The two sites are cross-linked as siblings.

Can the organization set or negotiate the split rate?

No. The split rate is part of the published model — a legal disclosure that counsel must clear and the founder must set. The exact rate is not disclosed on this page because it does not yet exist as a cleared, published figure. The organization does not negotiate or configure the rate. What the organization will see, before signing any agreement, is the exact disclosed rate and the full mechanism. The mechanism is described accurately here; the rate will be disclosed in the participation agreement when counsel and the founder have set it.

When does the organization actually receive a payout?

The payout sequence is: the payout rail (Stripe Connect school-side KYC plus the ACH disbursement flag) must be founder-enabled; a real lighthouse organization must be onboarded, papered, and paid end-to-end to prove the rail works; only after that does the model enter general availability. Until then, the ledger accrues a provable balance — every credit is dated and auditable — but no dollar moves. An organization in early access today will see the ledger structure, the agreements engine, and the dashboard in build; they will not receive a payout during the current phase. This is the honest description of where the model stands.

What does becoming an associate commit the organization to?

The participation agreement covers four things: (1) the organization’s opt-in as a fund beneficiary, which it can withdraw at any time; (2) payout consent — the organization agrees to receive disbursements when the payout rail is enabled; (3) data-processing terms consistent with the organization’s existing obligations; (4) the right to decline individually or withdraw from the programme entirely without penalty. The organization is not required to promote, advertise, or endorse the platform — promotion by the organization is entirely opt-in. The community fund dashboard shows a supporter count; the organization does not see individual supporter identities and is not asked to solicit them.

When is the model available, and what does early access involve?

The model is in active design and build. The exact-cents split engine and the agreements engine are built and production-ready; the community sub-ledger, the fund dashboard, and the live partner onboarding flow are in active development; the payout rail is honest-off. Early access is a conversation: we show the current state honestly — the agreements engine, the ledger structure, the split mechanics, and the dashboard in build — and discuss what a lighthouse associate partnership looks like before the payout rail is live. There is no pricing commitment and no signup. If it looks right for the organization, the next step is a participation agreement; that step does not happen until the model is ready and the agreement is counsel-cleared.