Afterschool.software
Book a conversation

Afterschool.software · Before- and after-school programs · Early access · 2026

Check-in grounded in who is actually here — and a ratio check that never marks an unruled age group as compliant

Afterschool.software is the operating platform for before- and after-school program directors and site coordinators. The operational core: persisted check-in and check-out events that the ratio engine reads directly, so the present count is always grounded in the attendance record — not in enrollment totals, not in a manual entry. The ratio check is fail-closed: an age group without a configured rule returns needs-data, never a silent pass. Daily sheets, enrichment clubs, enrollment, and billing rails round out the program record layer. Early access — no pricing commitment, no signup, no live payments today.

Book a conversation How it works
Fail-closedunruled age group → needs-data, never silent compliance — grounded in check-in events
Persisted eventscheck-in, check-out, daily sheet, enrichment-club, parent update — all stored
FERPA rep-wallonly aggregate counts and opaque refs cross boundaries — no child name or ref leaves the tenant
Consent-gatedenrollment requires opt-in — data owned by the organisation, never sold

The ratio check — the operational core of a licensed program

Staffing ratios grounded in who is actually checked in — not in who is supposed to be there

A before- or after-school program operates under a staffing-ratio requirement: for every N children in a given age group, there must be at least M adults present. The requirement is real, and the liability for non-compliance is real. Most platforms compute the required staffing count from enrollment capacity — a fixed number that does not change when three students are absent or two leave at 4 p.m. Afterschool.software reads the count from the persisted check-in events recorded that day: how many students are currently checked in, by age group, right now. A coordinator who is at 18 students at 3 p.m. and drops to 14 by 4 p.m. sees the ratio status reflect that change — because the count changed.

The fail-closed guarantee is the other half of the picture. A program running kindergartners and second-graders in the same room has two age groups, each potentially carrying a different staffing requirement under state licensing. If the program has configured a rule for second-graders but not for kindergartners, the engine returns needs-data for the kindergarten group — not “compliant,” not a warning note, but an explicit flag that the administrator must supply the missing rule before the engine can evaluate that group. Silence is never compliance. The rule set is caller-signed: the organisation’s administrator owns and maintains the ratio rules; the engine enforces them.

The check-in and check-out engine and the ratio check engine are built and production-ready. Per-state ratio rule sets are caller-signed; the platform never hard-codes a live compliance threshold. AI-assisted staffing suggestions are engine-absent: the surface is designed, no AI engine is provisioned.

Book a conversation Full platform

How it works

The program year in four stages

Afterschool.software runs on a program-year rhythm: configure the program and consent framework before the first day, run check-in and ratio monitoring through the program year, close each day with a complete daily-sheet record, and export at year-end. Every stage is described as it is built today.

Step 1 · Program setup — configuration, ratio rules, and consent

Before the first program day, the director configures the program: session schedule, age groups, capacity per slot, and the per-state staffing-ratio rules that the engine will use for ratio checks. Ratio rules are configured and signed by the organisation — the engine never substitutes a default. Enrollment opens once the program is configured and the consent framework is in place: a family must opt in to the program’s data handling before their child is enrolled. The organisation owns its roster from the first enrollment record.

Step 2 · Program day — check-in, ratio monitoring, daily sheet, enrichment

The program day opens with a check-in gate. Each arriving student’s check-in is recorded as a persisted event. The ratio engine reads the present count from those events and evaluates it against the configured ratio rules in real time. A coordinator sees the current ratio status: compliant, non-compliant, or needs-data for an age group without a rule. The daily sheet captures incidents, activities, and meal service as the day runs. Enrichment-club sessions track their own attendance alongside the main program record. At check-out, the safe-release gate validates the authorised pickup list before the departure event is written.

Step 3 · Parent communication and daily close — updates, billing events, records

At close, the day’s daily sheet is complete: check-in times, check-out times, enrichment sessions, and any parent updates recorded. Parent updates — notes about a child’s day communicated to the family — are stored as their own event type, separate from the daily sheet. Late-pickup events are recorded in the fee ledger if applicable. No charge is triggered today — the fee ledger builds the record, and the charge rail remains honest-off until enabled. The daily sheet is exportable at close.

Step 4 · Year-end — ledger review, consent audit, and record export

At the program year’s close, the organisation has a complete record: every check-in and check-out event, every daily sheet, every enrichment-club session, every parent update, and every billing event in the ledger. Consent status is auditable: every enrolled student has a recorded opt-in. One-click export delivers the full record in a portable format — the organisation owns its data. If the organisation ever leaves the platform, every record leaves with it: attendance history, enrollment records, daily sheets, enrichment logs, billing ledger entries, and consent status.

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

Check-in and check-out — persisted attendance events, real-time count

Every student arrival and departure is recorded as a persisted check-in or check-out event in the attendance store. The record is written at the moment of the event, not reconstructed at the end of the day from a paper sheet. The ratio engine reads directly from those persisted events to compute how many students are currently present — not from a head count entered manually, not from enrollment totals, not from an estimate. A site coordinator sees the live present count at any moment in the program day. Safe-release rules are enforced at the check-out gate: an authorised pickup list is validated before the event is written. The check-in and check-out engine is built and production-ready.

Built · production-ready

Fail-closed ratio check — unruled age group reports needs-data, never silent compliance

The ratio engine runs a pure check: given the age groups of students currently checked in and the per-state staffing rules for this program type, how many adults are required, how many are present, and is the program in compliance? The present count comes from the persisted check-in events, not from a configured number. Per-state ratio rules are caller-signed: the engine never hard-codes a live compliance threshold — the organisation’s administrator supplies and owns the rule set. An age group for which no rule has been provided returns a needs-data result — not a “compliant” status, not a warning, but an explicit flag that the engine has no rule to evaluate. This is the fail-closed guarantee: silence is never compliance. The ratio check engine is built and production-ready.

Built · fail-closed ratio engine production-ready

Daily sheets, enrichment clubs, and parent updates — the program record layer

The daily sheet is the operational record of a program day: attendance events, any incidents, meal service, and the activities run. It is persisted from the moment the day opens and updated in real time as the program runs. Enrichment-club sessions (clubs that run within the before- or after-school program) are tracked as their own session records alongside the daily sheet — club attendance and activity are distinct from the overall program attendance. Parent updates — a structured event that records what a family was told about their child’s program day — are stored as a separate persisted event type. The daily sheet, enrichment-club, and parent-update stores are built and production-ready. The AI-assisted parent-update draft (a suggested message generated by an AI engine) is engine-absent: the assist surface exists in the codebase as an honest-off capability, with no AI engine provisioned.

Daily sheet & enrichment stores built · AI-assist engine-absent

Enrollment and waitlist — program roster, slot-managed, consent-gated

Program enrollment records a family’s commitment to a specific program and session: the student, the program, the start date, the slot. The enrollment store is built and persisted. The waitlist is a queue managed at the program level — when a slot opens, the next eligible family on the waitlist can be offered the place. Enrollment is consent-gated: a family must have an active, recorded consent to enroll their child in a program that includes minors’ data handling. Only aggregate counts and opaque program identifiers cross service boundaries; no child name or reference is passed outside the tenant. The enrollment and waitlist engines are built and production-ready. The AI-assisted waitlist-fill suggest (a ranked recommendation of which waitlisted families to contact next) is engine-absent: no AI engine is provisioned.

Enrollment built · waitlist-fill AI engine-absent

Billing rails — recurring tuition, late-pickup fee ledger, and subsidy-voucher billing

Three billing rails are built as a ledger substrate: a recurring-tuition billing record per enrollment (schedule, amount, and status tracked in the ledger); a late-pickup fee ledger that records assessed fees per event against the family’s account; and a subsidy-voucher billing record that applies an external voucher (state, district, or program-funded) against the family’s balance. Each is a built data model and ledger operation. The charge rail that moves money — the part that triggers a real payment transaction against a family’s card or bank account — is honest-off: present in the platform, not enabled for live transactions today. No billing statement is sent, no charge is triggered, and no payment is collected until the charge rail is enabled.

Billing ledger built · charge rail honest-off

Who uses it

Program directors, site coordinators, and business offices — three views of the same platform

Program director

The program director configures the program: session schedule, capacity, age groups, and the per-state ratio rules the engine will enforce. At the start of the year, the director sets up enrollment and opens the waitlist. Across the year, the director reviews daily-sheet summaries, monitors ratio-check history to spot patterns, and manages enrichment-club offerings. Consent is auditable: every enrolled student has a recorded opt-in. The one-click year-end export delivers the full record in a portable format the director owns.

Site coordinator

The site coordinator runs the day. Check-in opens when the first student arrives; each arrival is recorded as a persisted event. The ratio status is visible in real time: compliant, non-compliant, or needs-data for an unruled group. The daily sheet accumulates as the day runs: incidents, activities, enrichment-club sessions, meal service. At the end of the day, the coordinator closes the check-out gate, validates the authorised-pickup list for each departure, and completes the daily sheet. Parent updates are recorded and stored as their own event type.

School business office

The business office sees the billing ledger: recurring-tuition billing records per enrollment, late-pickup fee entries per event, and subsidy-voucher billing records reducing family balances. The charge rail is honest-off — the ledger builds the record without moving money. The business office can model the billing picture, audit the ledger, and evaluate the platform’s fit for their subsidy-voucher reconciliation workflow before the charge rail is enabled.

FERPA rep-wall & family consent — the design constraint that protects student data

Only aggregate counts and opaque program references cross boundaries — never a child’s name or identifier

The platform is designed with a FERPA rep-wall as a structural constraint: no child name, no student identifier, and no individually identifiable education record crosses an external service boundary in any API call made by the platform. External calls carry only aggregate counts (how many students are currently present) and opaque program references (an identifier that maps to a program internally but carries no student information on its own). This is enforced at the design layer, not as an opt-in configuration.

Enrollment is consent-gated: a family must opt in to the program’s data handling before their child is enrolled. Consent is not assumed. It is recorded. Consent can be withdrawn at any time, and withdrawal is honoured: if a family withdraws consent, their child’s record is not included in any further data handling. The organisation owns its roster and its family consent records — not the platform. No family contact, no student record, and no attendance history is sold to or shared with outside companies or advertisers.

What is built and what is coming — plainly stated

The operational core is built. The charge rail and AI assists are not live yet.

Built and production-ready today: the check-in and check-out engine (persisted attendance events, safe-release gate, real-time present count); the fail-closed ratio check (the present count read from persisted check-in events, caller-signed per-state rules, needs-data for unruled age groups); the daily-sheet, enrichment-club, and parent-update stores; the enrollment and waitlist engines (consent-gated, slot-managed); and the billing rails as a ledger substrate (recurring-tuition billing records, late-pickup fee ledger, subsidy-voucher billing records).

Not yet enabled for live use: the charge rail (the part that moves money), live billing transactions against family payment instruments, and the AI assists for staffing suggestions, parent-update drafts, and waitlist-fill recommendations. These are honest-off — present in the platform’s design, not enabled for live use. There is no live checkout here. No billing charge. No AI engine running. We say so directly because a program director evaluating compliance tooling deserves to know what is production-ready and what is still being wired.

Connected to the school platform

The after-school program connects to the school’s publishing, recognition, and identity layer

Afterschool.software is the operational layer for the program day. The students who participate in after-school enrichment programs are the same students whose work appears in the school’s yearbook and newspaper, whose achievements are recognised through Seen — the recognition layer that puts every student on a real page with adviser approval — and whose school moments are captured by Assembly, the event and moment layer. Student IDs and program access at the school level connect through studentid.software. The school publishing platform at homeroom.software ties the publishing, recognition, and administrative layers together.

seen.school assembly.school studentid.software homeroom.software

Early access · Program directors, site coordinators, school business offices

Book a conversation to see the current state honestly

Afterschool.software is in active development. We do conversations that show the current state honestly: how check-in events are recorded and how the ratio engine reads them, how the fail-closed guarantee works for an unruled age group, how the daily sheet accumulates across a program day, how enrichment-club sessions are tracked alongside the main record, and how the billing ledger builds up for a recurring-tuition enrollment. There is no pricing commitment and no signup. If it looks right for your program, we discuss what early access looks like.

To book: email [email protected].

FAQ

Common questions

What does “fail-closed ratio check” mean, exactly?

It means the engine never silently marks an age group as compliant when it has no rule to evaluate. Most programs run multiple age groups — kindergartners, elementary grades, older students — and each may have a different staffing requirement under state licensing. If the program has not yet configured a rule for a specific age group, the engine returns a needs-data result for that group, not a passing status. There is no default “compliant.” A missing rule is flagged explicitly so the coordinator can resolve it, not overlooked because the system filled in a number. Fail-closed means silence is never treated as approval.

Where do the ratio numbers actually come from? Is it based on enrollment?

The present count used by the ratio engine comes from the persisted check-in events recorded during the program day — not from enrollment totals, not from capacity, not from a number someone enters at the start of the day. A student who is enrolled but not yet checked in does not count as present. A student who has checked out does not count as present. The ratio check is a live picture of who is in the room at the moment the check runs, grounded in the attendance record. This is the design intent: staffing ratios are about physical presence, not paperwork.

How are per-state ratio rules handled? Does the platform hard-code state licensing requirements?

No. Per-state ratio rules are caller-signed: the organisation’s administrator configures and owns the rule set. The engine evaluates the rules it is given; it does not have a built-in library of state licensing standards. This is an intentional design choice: licensing requirements change, and they vary by program type, setting, and age group within a state. The platform’s job is to enforce the rules correctly — the organisation’s job is to supply the current, authoritative rules. An age group with no rule configured returns needs-data, which prompts the administrator to supply the missing rule.

What is stored in the daily sheet? Is it more than just attendance?

The daily sheet is the full operational record of a program day. It includes the check-in and check-out events for every student, any incidents documented during the day, meal service records, and the activities conducted. Enrichment-club sessions are stored as their own session records alongside the daily sheet — club attendance is distinct from the program’s overall attendance record. Parent updates — structured notes about a specific child’s day communicated to the family — are stored as a separate event type. The daily sheet is the auditable record of what happened and who was present.

What is an enrichment club session, and how is it different from the daily program?

An enrichment club is an activity that runs within the before- or after-school program with its own membership and session record — a homework club, a coding club, a sports team practice running under the program umbrella. Enrichment-club sessions track their own attendance: which students participated in that specific club session, separate from the main program’s check-in record. The enrichment-club store is built and persisted alongside the daily sheet store. A student can be checked in to the program and also have an enrichment-club session record for the same day.

How does the subsidy voucher work? Can the platform handle state-funded vouchers?

The subsidy-voucher billing rail records an external voucher — a state-funded childcare subsidy, a district grant, or a program-sponsored reduction — applied against a family’s account balance. The voucher billing record is built and persisted: it captures the voucher source, the amount, and the enrollment it applies to. The charge rail that moves money is honest-off: the ledger records the voucher and reduces the family’s balance in the record, but no transaction is triggered against a payment instrument until the charge rail is enabled. This means the billing model is fully describable today, and the platform can be evaluated for fit, without live payment processing.

What are the AI assists? Are they available?

Three AI-assisted capabilities exist in the codebase with honest-off status: a staffing-from-ratio suggest (a recommendation of how many additional staff are needed based on the current ratio check), a parent-update-draft assist (a suggested message draft for the day’s parent update), and a waitlist-fill suggest (a ranked recommendation of which waitlisted families to contact when a slot opens). All three return available:false with an engine_absent status. No AI engine is provisioned. We describe these honestly: the surface and the interface are designed, but no AI engine runs behind them today. We will not fabricate a suggestion to fill the space.

How does enrollment work? What is the waitlist?

Enrollment records a family’s commitment to a specific program and session: the student, the program, the start date, and the slot. The enrollment store is built and persisted. The waitlist is a queue at the program level: when a slot opens (because of a withdrawal, a no-show, or a capacity expansion), the next eligible family on the waitlist can be offered the place. Enrollment is consent-gated: a family must have an active recorded consent before their child is enrolled in a program that handles minors’ data. The enrollment and waitlist engines are built and production-ready.

Is the billing live? Can we collect tuition, late-pickup fees, or subsidy voucher reconciliation now?

Not yet. The billing rails — recurring tuition billing records, late-pickup fee ledger entries, and subsidy-voucher billing records — are built as ledger substrates. The records are written, the balances are tracked, and the model is fully auditable. The charge rail that triggers a real payment transaction is honest-off: it exists in the platform, not enabled for live transactions today. There is no live billing, no subscription charge, and no payment collected. When the charge rail is enabled (a founder-gated decision), organisations will be notified. A conversation today shows the billing model, not a live payment screen.

How is family and student data handled? What about FERPA?

Family and minor student data is owned by the organisation running the program, not by the platform. No student record, family contact, or attendance history is sold to or shared with outside companies or advertisers. Only aggregate counts and opaque program references cross service boundaries — no child name or student identifier leaves the tenant in any external call. This is the FERPA rep-wall: the design constraint that prevents individual student data from crossing external API boundaries. Consent is required before enrollment and can be withdrawn at any time. One-click export delivers every record in a portable format if the organisation ever leaves.

What can we actually see in a conversation today?

In a conversation we walk through the current state honestly: how check-in events are recorded and how the ratio engine reads them to produce a present count; how the fail-closed guarantee works for an age group with no rule configured; how the daily sheet accumulates over a program day; how enrichment-club sessions are tracked alongside the main record; and how the billing ledger entries build up for a recurring-tuition enrollment. None of that involves live payments, live AI suggestions, or a live booking flow today. The conversation is the honest next step: we show what is built, describe what is honest-off, and discuss whether early access makes sense for your program.