Associate · Community software suite · Early access · 2026

Professional software built on our own substrate — with a selectable school community fund that accrues a provable balance on every renewal

Associate is a suite of professional tools — e-sign agreements, helpdesk, forms, booking and scheduling, invoicing — built entirely from the platform’s own apps, not third-party SaaS licensed and resold under a new name. Each plan carries a selectable school community beneficiary: a school community organisation you name, whose community fund receives a provable exact-cents credit every time your subscription renews. The suite ships as plain software first; the community fund mechanism is described honestly as a model in development. Early access — no pricing commitment, no signup, no live payments today.

Book a conversation How it works

Exact centsinteger-cents ledger — fee off gross first, largest-remainder reconciled, no silent rounding

Own substrateevery app is ours — not third-party SaaS assembled under a new name

School-chosenone named, verified school per subscription — your choice, held in the ledger

Firewallstudent PII and school-roster data never cross to this suite — structural, not policy

Why the community fund works on this substrate — and not on someone else’s

Software you would subscribe to anyway — structured so that choosing it can one day fund a school community you name

The software in the Associate suite runs on a substrate that is already built and shared across a whole platform of products. One more subscriber does not generate the per-seat infrastructure cost that a stitched-together SaaS resale operation carries. That near-zero marginal cost is the structural fact that makes a meaningful school-community split possible — we split from our own price, not from a thin slice of a third party’s retail margin. The ceiling on what we can credit to a school is set by our own economics, not by someone else’s acquisition-cost tolerance.

The specific split rate is a founder decision and a legal disclosure that counsel must clear before it is stated anywhere. We describe the structural advantage plainly — it is real — and leave the exact figure to be stated when it can be stated honestly. What we will say: the ceiling is meaningfully higher than scrip and cashback programmes that split a retailer’s thin margin, because we are not constrained by a retailer’s margin at all.

The community you name becomes a natural part of the channel: a school community organisation that benefits from the fund has every reason to talk about it to the community it already serves. That converts a cold-acquisition software problem into a warm, community-endorsed one — without requiring the school to actively advertise or endorse the product (the community fund’s distribution effect works through the school’s existing relationships, not through a mandate). Until the payout rail is founder-enabled, the fund accrues a provable balance but pays nothing. The accrual is real; the payout is the later, founder-gated event.

Book a conversation The full suite

How it works

The subscription and accrual rhythm in four stages

Associate runs on a four-stage rhythm: subscribe and choose your school beneficiary, work with the suite, accrue a provable credit on every renewal, and eventually watch the fund flow to the school when the payout rail is enabled. Every stage is described honestly — including which parts are live and which are founder-gated.

Step 1 · Subscribe — plan, school beneficiary, and community-supporter terms

You choose a plan based on the tools you need: a personal plan for a freelancer or teacher’s side-practice, a small-business plan for a solo operator or consultant, or a community-organisation plan for a group that runs events, shared forms, or helpdesk. At the time of subscription you name a school community organisation as your beneficiary — typeahead search from the verified-school directory, one named school per subscription. You accept the community-supporter terms, which describe the split mechanism, the accrual-only posture, the no-guarantee-of-payout language, and the school’s right to decline. This step is described as future-conditional: the subscription rails are honest-off today, so no payment is taken and no subscription is established yet.

Step 2 · Work with the suite — the software you actually need

The suite is built from the platform’s own apps: the agreements engine for e-sign documents; the helpdesk for client support tickets; forms and the docs workspace for data collection and collaborative writing; booking and scheduling for appointments; invoicing for billing records. Each app is honest about its state — the agreements engine and helpdesk core are built and production-ready; the delivery surfaces (email carrier, builder interfaces, payment checkout) are honest-off while in active development. You do not use school data, school records, or any student information through this suite. The PII firewall between the school platform and the community suite is structural: your account type is denied access to every school-facing module by construction.

Step 3 · Accrue — each renewal posts a provable exact-cents credit

Each time your subscription renews, the billing handler posts an exact-cents credit to your named school’s community-fund sub-ledger. The split is computed server-side and the credit is an integer number of cents — no floating-point rounding, no silent coercion. The fee is deducted from the gross first; the split is applied to the net remainder; a largest-remainder reconciliation pass ensures the ledger entry equals exactly what was credited, with no penny disappearing. The sub-ledger is add-only by convention, with a unique posting key per event — 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. The fund accrues a provable balance with every renewal. The payout rail is honest-off: the accrual is real; the payout is a later, founder-gated event.

Step 4 · The school sees its community fund grow — and eventually receives it

The school’s community-fund dashboard — in active development — is designed to show an aggregate integer-cents balance, a dated credit history, and a supporter count — no subscriber identities, no subscriber PII on the school-side view. When the payout rail is founder-enabled — the ACH disburse and school-side KYC steps are the gate — the accrued balance flows to the school on a threshold-triggered schedule. Until the suite and its ledger go live, nothing has accrued yet; once live, the dashboard is designed to be a real-time record of what has accrued. No school is currently receiving payouts. The honest description: the accrual begins when the suite goes live; the payout is a later event, gated on the founder-enabled switch and the school’s completed participation agreement.

All five apps

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 carrier integration is in active build. We do not claim otherwise.

Agreements and e-sign — a tamper-evident document engine for independent work

The agreements engine handles the complete lifecycle of a signed document: draft, send-for-signature, countersign, notify all parties, and store the signed record. Each signed document carries a SHA-256 content seal computed over the exact signed bytes at send time — proof of exactly what was signed. Ten agreement kinds are defined in the engine today, each with its own field set and signing sequence: the platform’s own business agreements — a reseller master services agreement, a studio–school agreement, a SaaS school licence, a data-processing agreement, an order form, and a sales-rep agreement — plus four consent-document kinds that route through a separate student-agreement path, because a minor is never bound to a contract. Contractor agreements, service terms, and scope-of-work letters for independent work are not among the ten yet; those community-suite kinds are being defined on the same engine. The agreements engine is built and production-ready. The HTTP delivery door — the mechanism that sends a signing link to a counterparty, receives the signature, notifies all parties on completion, and stores the countersigned record — is in active development. The email carrier that delivers those notifications is honest-off — present in the platform, not enabled for live delivery today. There is no live e-sign delivery today.

Agreements engine built · delivery door in active development

Helpdesk — a ticket-based support layer for the work you do with clients

The helpdesk core manages inbound support requests as structured tickets: created, assigned, tracked through status changes, and closed with a full history record. For a solo operator or a small team, a helpdesk replaces the mental overhead of tracking which client asked about which problem in which email thread. The helpdesk core is built and production-ready. The email carrier is honest-off — the part that routes inbound email into a ticket and sends replies back out is present in the platform, not enabled for live email routing today. The generic non-school-branded visual skin — the school-specific version exists; the community-suite version is being built — is in active development. There is no live email-to-ticket routing today.

Helpdesk core built · email carrier honest-off

Forms and documents — data collection and a collaborative workspace

The documents substrate — collaborative text documents and structured sheets — is built as part of the platform’s workspace layer. It ships as a bundle sweetener alongside the community suite: built and production-ready on the substrate, not yet surfaced as a live offering for community-suite accounts. Forms — configurable data-collection forms with field definitions, response collection, and structured output — are in active development. The form-definition substrate and the response-record model are built. The form-builder interface is honest-off — the surface that lets a user define and publish a form without writing code is in active development; the substrate is built, the builder door is not yet live. For small organisations, forms replace ad-hoc spreadsheet-link approaches without requiring a separate outside subscription.

Docs substrate built · forms builder honest-off

Booking, scheduling, and invoicing — appointments and billing on one substrate

The scheduling core manages availability windows, bookable slot types, and appointment records. The invoicing substrate manages line items, issued invoices, and payment-expected records. Together they cover the core workflow of a service-based operator: a client books a slot, a record is created, an invoice is generated on completion, and payment is tracked against it. The scheduling core and the invoicing substrate are built on the platform’s commerce layer. A generic entry path — one that does not require a school roster as the booking source — is in active development for the community suite. The payment rail is honest-off — the same founder-gated switch that gates the community fund’s payout mechanism; it does not accept deposits or process invoice payments today. No live checkout, no billing.

Scheduling core built · payment rail honest-off

Community fund — an exact-cents accrual toward the school community organisation you name

The community fund mechanism runs on the platform’s exact-cents split engine and the platform’s integer-cents ledger substrate. When you subscribe, you name a school community organisation as your beneficiary from a directory of verified schools. Each time a subscription renews, the billing handler is designed to post an exact-cents credit to that school’s community-fund sub-ledger — computed server-side, never caller-supplied, fee-off-gross-first, largest-remainder reconciled. Each ledger entry is add-only by convention, with a unique posting key per event — 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. The school-side community-fund dashboard — in active development — is designed to show the aggregate balance, a dated credit history, and a supporter count, with no subscriber identities shown and no subscriber PII crossing to the school-side view. The exact-cents split engine is built and production-ready, and the integer-cents ledger substrate it posts to is built; the community-fund sub-ledger and the school-side dashboard are the thin per-school new kind riding that substrate, in active development. The payout rail is honest-off — the mechanism that would move the accrued balance to the school via ACH disburse is present in the platform, not enabled for live transactions. The fund accrues a provable balance but pays nothing until the payout rail is founder-enabled. No school is named as already earning or already paid.

Split engine built · payout rail honest-off

Who uses it

One substrate, three buyer profiles — each with a different natural use of the suite

Freelancers and teachers with a side-practice

A freelancer or a teacher running a tutoring practice, a music studio, or a consulting side-business needs two things the most: agreements that hold up (e-sign documents a client signs digitally, each sealed with a SHA-256 hash of the exact signed bytes) and a helpdesk that keeps client requests sorted (tickets, not email threads). Invoicing closes the loop: an invoice issued against a completed job, payment tracked against it. The suite covers all three on the same subscription. The school community fund lets a freelancer whose work is adjacent to a school community channel part of their recurring cost toward a school they already care about.

Small businesses and consultants

A small business or a solo consultant runs the same operational loop, scaled: agreements for scope-of-work letters and service terms; a helpdesk for client support across multiple engagements; booking and scheduling so clients book without back-and-forth; invoicing tied to those bookings so the billing cycle is not a separate manual step. Forms round out the stack for intake questionnaires, onboarding, and feedback collection. The school community fund is a selectable commitment a business can make to a named school — not a donation, not a surcharge, but a structural feature of choosing this suite over another.

Community organisations and parents

A community organisation — a church group, a community theatre, a sports club, a parent-teacher organisation or booster club — needs the same operational tools as a small business: helpdesk for member inquiries, forms for event registration, booking for facility use, invoicing for membership dues. For a community organisation already connected to a school, naming that school as the community fund beneficiary is a natural act: the organisation supports the school it came from, and the fund accrues on every renewal. A parent subscribing “even if it’s for their business” can name their child’s school as the beneficiary. The mechanism is the same regardless of buyer type.

The community fund model — how the accrual works

An exact-cents ledger that accrues toward a school you name — described honestly

The community fund accrual runs on the platform’s split engine: fee off the gross first, split applied to the net remainder, largest-remainder reconciliation so the ledger entry always equals exactly what was credited. The credit is posted as an integer number of cents — no floating-point rounding, no silent coercion, and a largest-remainder reconciliation so the ledger entry equals exactly what was credited to the cent. The engine is the same one that runs booster club fundraising splits on the same substrate. It is built and production-ready.

The school’s community-fund dashboard — in active development — is designed to show the aggregate balance, a dated credit history, and a supporter count. It never shows subscriber identities — the ledger row has no subscriber reference by schema, not by policy. Once the suite is live, a school treasurer will be able to see that the fund has grown, can see each renewal credit with its date and amount, and can see how many supporters are contributing — without knowing who any of them are. That is the privacy design: the school sees the fund; it does not see the supporters.

The split rate is a founder decision that counsel must clear before it is disclosed. We describe the structural reason the rate can be meaningfully higher than scrip and cashback programmes, and we leave the exact rate to be stated when it can be stated honestly. The accrual is real and the ledger is real; the payout is a later, founder-gated event. We say this plainly because describing an accrual that does not yet pay as if it pays would be false.

Your data & the structural firewall

Your data is yours. Student data never crosses to this suite.

Subscriber data is owned by the subscriber — not by the platform. No subscriber data is sold to or shared with outside companies or advertisers. The community-fund ledger is the only data that touches the school-side view, and it carries no subscriber identity: only an integer-cents credit amount and a timestamp. Consent to marketing communications can be withdrawn at any time.

The community suite is structurally isolated from the school platform’s student data, school-roster records, minors’ consent records, and minors’ imagery. A community-suite account type is denied every school-admin module by construction — the SIS, gradebook, consent ledger, photography pipeline, and yearbook engine are out of reach at the entitlement layer. This is not a policy reminder. It is a structural gate enforced in code: the missing entitlement row means denied, not just warned.

The community-fund ledger has no student reference, by schema. The school-side dashboard does not join to any student row. A school viewing its community-fund dashboard sees a fund balance and a supporter count; it cannot navigate from the fund to a student record, because no such link exists in the data.

What is built and what is coming — plainly stated

The engines are built. The delivery surfaces and the payment rails are not live yet.

Built and production-ready today: the agreements engine (SHA-256 content-sealed, ten agreement kinds, full signing lifecycle); the helpdesk core (structured tickets, assignment, history records); the documents substrate (collaborative text and structured sheets, workspace layer); the scheduling core and invoicing substrate (availability windows, appointment records, line items, payment-expected records); the exact-cents split engine (fee-off-gross-first, largest-remainder reconciliation, integer-cents); and the integer-cents ledger substrate the community-fund sub-ledger rides (add-only by convention, unique posting key, RLS-isolated — the same idempotency pattern used across the platform).

Still being built — in active development, not yet finished: the community-fund sub-ledger (the per-school new kind riding the built ledger substrate); the HTTP delivery door for e-sign (send-link, sign, countersign, notify, store); and the form-builder interface (form definition, publication, response collection). Honest-off — present in the platform and built, but the live switch has not been thrown: the email carrier (inbound routing, outbound notifications for e-sign and helpdesk); the payment rail (the part that accepts deposits and processes invoice payments); and the payout rail (the ACH disburse mechanism that moves the accrued community-fund balance to the school). There is no live checkout here. No billing. No subscription. No school receiving a payout. We say so directly because the people who might subscribe deserve to know what is production-ready, what is still being built, and what is built but founder-gated.

The two ends of one loop — and the wider platform

Associate Software and Associate Network — one model, two storefronts

associate.network is the organisation-facing side: how a school community organisation opts in as a fund beneficiary, the participation agreement, the community-fund dashboard, and the school’s view of what has accrued on its behalf. This site is the buyer side — the suite you subscribe to and the school you choose. The two are designed to be visited from both ends: a school community treasurer looking at the fund visits associate.network; a parent or freelancer looking for the software they subscribe to visits here.

The community suite runs on the same substrate as the wider school platform. Assembly is the moment layer — live school events captured, ticketed, and archived. Seen is the recognition programme — adviser-approved, consent-verified recognition that flows automatically into school publications. homeroom.software is the publishing platform — the free digital yearbook, the newspaper engine, and the consent substrate that makes it safe for schools. The community fund accrues toward a school that may also be using any of these products; the fund is a single ledger entry, not a dependency on any of them.

associate.network assembly.school seen.school homeroom.software

Early access · Freelancers, consultants, small businesses, community organisations

Book a conversation to see the current state honestly

Associate is in active development. We do conversations that show the current state honestly: what the agreements engine does today (the tamper-evident lifecycle, the ten agreement kinds), what the helpdesk core looks like in build (structured tickets, assignment, history), how the community-fund accrual works (the split engine, the integer-cents ledger, the school picker), and what the timeline looks like for live delivery surfaces and the payment rail. There is no pricing commitment and no signup. If it looks right for your practice or organisation, we discuss what early access looks like.

To book: email [email protected].

FAQ

Common questions

What software is actually in the Associate suite?

The v1 suite is built from the platform’s own apps: an e-sign agreements engine (SHA-256 content-sealed, ten agreement kinds); a helpdesk for client support tickets; a forms and documents workspace; booking and scheduling for appointments; and invoicing. The agreements engine and the helpdesk core are the shortest path to a live product — their engines are built, and the delivery surfaces (email carrier, builder interfaces) are in active development. Booking, scheduling, and invoicing are built on the commerce substrate and gate on the same payment rail as the community fund’s payout mechanism. We do not describe a feature as working end-to-end when it is not.

Is the payment rail live? Can I use the suite today?

Not yet. The agreements engine, the helpdesk core, and the documents substrate are built and production-ready. The delivery surfaces — the email carrier, the HTTP delivery door for e-sign, the form-builder interface — are in active development. The payment rail that accepts deposits and processes invoice payments is honest-off: present in the platform, not enabled for live transactions. There is no live checkout, no billing, and no subscription today. A conversation is the honest next step, not a “sign up and pay.”

What is the community fund mechanism? How does it work?

When you subscribe, you name a school community organisation as your beneficiary. Each renewal, the platform’s exact-cents split engine posts a credit to that school’s community-fund sub-ledger — integer cents, computed server-side, fee-off-gross-first, largest-remainder reconciled. The sub-ledger is add-only by convention, with a unique posting key per event — 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. The school’s community-fund dashboard shows the aggregate balance, a dated credit history, and a supporter count. No subscriber identities are shown on the school-side view — the PII firewall holds at the schema level.

How and when does the school actually receive the money?

The payout rail — the mechanism that moves the accrued balance to the school via ACH disburse — is honest-off: it exists in the platform but is not enabled for live transactions. The fund accrues a provable integer-cents balance with every renewal, but pays nothing until the payout rail is founder-enabled and a real school has completed the participation agreement and KYC. We do not claim that any school is being paid today, because that would be false until the rail runs. The honest description: the fund accrues; the payout is a later, founder-gated event.

Is my subscription contribution tax-deductible as a charitable donation?

No. You pay full price for the software you are using — you receive the full fair-market value of the suite in exchange for your subscription fee. The split that accrues to the school is funded by us from our own price, not an additional payment by you on top of the subscription. Because you receive full value for your payment, there is no deductible component. This is not structured as a charitable donation by the subscriber, and we do not describe it as one. Any tax questions specific to your situation are for your own tax adviser.

Can I choose any school as my beneficiary?

You choose from a directory of verified schools — the same NCES-sourced directory of over 130,000 schools the platform uses for school identification. A school becomes a fund-eligible beneficiary after completing a participation agreement that establishes the fund’s terms, payout consent, and data-processing conditions. The beneficiary picker and the fund-eligibility filter are in active development; by design, the picker typeahead will show only schools that have opted in to the programme, and a school that has not consented cannot appear as a beneficiary option.

What can the school see about supporters?

The school’s community-fund dashboard is in active development; by design it shows three things: the aggregate integer-cents balance, a dated credit history (amounts and timestamps, not subscriber identities), and a supporter count. No subscriber name, email address, or any personally-identifying information is visible on the school-side view. The community-fund ledger row has no subscriber reference — enforced at the schema level, not by policy that could be overridden. By design, the school will see what the fund has accrued; it does not see who contributed.

What about student data and minors? Does this suite touch any of that?

No. The community suite is structurally isolated from the school platform’s student data, school-roster records, minors’ consent records, and minors’ imagery. A community-suite account type is denied every school-admin module by construction — the SIS, gradebook, consent ledger, photography pipeline, yearbook engine, and school-directory data product are all out of reach at the entitlement layer. This is a structural firewall, not a policy reminder that could be overridden by an administrator.

What does “honest-off” mean?

“Honest-off” is the term we use for a feature whose code is present in the platform and built, but whose live switch has not been thrown — so it does nothing for a real user yet. The email carrier, the payment rail, and the payout rail are honest-off in exactly that sense: the logic is built; the switch is founder-gated and has not been turned on. Two other surfaces named on this page — the e-sign delivery door and the form-builder interface — are not honest-off yet; they are in active development, still being built, which is why we describe them that way rather than as finished-and-switched-off. We use “honest-off” instead of “coming soon” because “coming soon” implies a timeline we have not committed to publicly. The CTA here is not “sign up and pay” — it is “book a conversation.”

Is my subscriber data sold or shared with the school?

No. Subscriber data is owned by the subscriber and is never sold to or shared with outside companies or advertisers. The community-fund ledger is the only data that touches the school-side view, and it carries no subscriber identity — only an integer-cents credit amount and a timestamp. The subscriber’s name, email, payment information, and all personally-identifying information stay on the subscriber side. Consent to marketing communications can be withdrawn at any time.

What is the relationship between associate.software and associate.network?

associate.network is the organisation-facing side of the same model: how a school community organisation opts in as a fund beneficiary, the participation agreement process, the community-fund dashboard, and the school’s view of what has accrued. Associate Software is the buyer and supporter storefront: the suite you subscribe to, the school you choose, and the accrual that builds the fund. The two sites are the two ends of one loop, built as distinct products on the same substrate and intentionally cross-linked rather than merged.