Childcare software built around consent, compliance, and cash flow — not a binder and a parent app stapled together

Every meaningful action in a childcare platform touches a child’s personal information: a photo goes to a parent, a roster goes to a photographer, a medication is administered, a pickup is authorised, a billing contact is notified. In most platforms those decisions are implicit — staff are trusted to remember which families consented to what, or a single “I agree” checkbox at enrollment is supposed to cover every future use. The Child Consent Ledger makes each decision explicit: a time-stamped record of what was consented to, by which guardian, for which specific use case, with revocation available at any time. Revocation is immediate and enforced at the engine: a photo locked by a revoked consent does not appear in daily reports, does not export to the yearbook, and does not show in a media share, without any manual action from a staff member. The ledger is also the audit export: a director can produce the full consent history for every child for a licensing inspection.

Not yet. The tuition billing engine — the part that calculates tuition plans, applies sibling discounts, tracks subsidy receivables, records receipts, and produces tax statements — is built and production-ready on the tuition.software substrate. The charge rail, the part that moves money from a family’s ACH or card to the center’s account, is honest-off: it exists in the platform but is not enabled for live transactions today. There is no live checkout, no billing, and no subscription. When the charge rail is enabled (a founder-gated decision), programs will be notified. A conversation is the honest next step — we show the billing engine working in a demo and discuss what early access looks like.

A parent arrives and scans a QR code or enters a PIN at the check-in screen. The engine looks up the child’s authorised-pickup list from the consent ledger and either admits the pickup or flags a mismatch for staff review — a guardian not on the list cannot check out a child, enforced at the engine. Staff clock in and out against specific classrooms; the ratio monitor tracks the licensed child-to-staff ratio in each room in real time. A ratio warning surfaces before the violation occurs — not logged after the fact — so a director or lead teacher can act. Classroom transfers are logged, and late-pickup tracking records departure times against a configured pickup window. All of this lands in the same audit trail as the consent records.

The compliance cockpit is built around the records a licensing inspector asks for on arrival: immunisation records per child with expiration alerts, incident reports written at the time of the event and locked after guardian sign-off, medication-administration logs requiring prior authorisation, staff-certification dates with renewal alerts, and background-check dates per staff member. The South Carolina licensing checklist mapping is the initial compliance surface — a director can see which of the required record types are complete and which have gaps, without manual cross-referencing. The inspection binder export, which assembles the required records into a portable printable package, is in active development. Additional state configurations follow SC. The underlying records model is built; the binder-export UI and CACFP meal-count export are in active development.

The communications engine sends daily reports, classroom announcements, direct messages, and controlled media shares to opted-in families. Every family requires a prior opt-in before receiving any message — no message reaches a family that has not opted in. The channel infrastructure, templates, and media-consent matching are built and production-ready. Live carrier delivery — the SMTP and SMS carrier connections that actually deliver the message to a family’s inbox or phone — is key-gated: it requires configured provider keys and is honest-off today. In a demo we walk through the full compose-and-send flow; the delivery leg is marked clearly as in active configuration. There is no parent social feed, no comment thread, no public photo album, and no enrichment marketplace.

The photography bridge connects childcare enrollment and consent records to a picture-day session. Before a photographer arrives, the bridge exports a roster that carries only what the photographer needs — name, class, and make-up day flag — without exposing medical, billing, or custody data. The export is filtered against the media-consent record from the Child Consent Ledger: a child whose family has not consented to photography is not included, and the photographer never sees a name or an image for that child. After the session, parent purchase links go to opted-in families only; the order handoff does not expose child data to the lab or the order platform. Sibling linking handles families with multiple children across classrooms. The photography and yearbook bridge is built and production-ready.

We are careful about what we claim here. FERPA applies to education records at schools that receive federal funding — district-run early childhood programs and some preschools operating within a public school district fall within its scope. Our architecture is FERPA-aware: education records are access-controlled, audit-logged, and exportable to a guardian on request; we do not share them with third parties without the legally required authorisation. COPPA applies to online collection of personal information from children under 13 — we are COPPA-conscious: no behavioural advertising, no third-party tracking, no child data monetised or sold. We do not claim a SOC2 certification, a HIPAA covered-entity status, or a FERPA-certified badge — those are specific designations we have not yet earned and will not claim in advance. The security statement on this page describes our actual posture honestly.

No. The parent communication engine is a controlled, one-directional-by-default channel: the center sends daily reports, announcements, and direct messages to opted-in families. There is no parent-to-parent feed, no comment thread on a child’s daily report, no public photo album, no community forum, and no social-media-style notification stream. A parent who does not opt in to communications receives no messages — they can still access their child’s consent and billing records through the guardian portal, but they are not enrolled in a communication list without their explicit choice. This is by design. A childcare platform that looks like a social network creates data-hygiene and minor-safety risks the platform should not introduce.

The platform is in active development. In a demo we walk through the current state honestly: the check-in screen running a simulated arrival against an authorised-pickup list; the ratio monitor updating as classrooms fill; the consent ledger showing a complete per-child consent record with a revocation; the billing engine modelling a tuition plan with a subsidy and a sibling discount before the charge rail is enabled; and the compliance cockpit showing an immunisation record with an expiration alert. None of those involve live payments or live carrier delivery today. A conversation is the honest next step — we show what is built, what the charge-rail and compliance-surface timelines look like, and what early access means for your program.

The organisation owns its data. One-click export is available in writing — if the program ever leaves the platform, every record leaves with it: enrollment history, attendance logs, billing ledger, consent records, incident reports, medication-administration logs, and communication history. The export is in a portable format a director can read without the platform. Records for children who age out of the program are deleted under the configured retention window — the platform does not hold a permanent archive of child data beyond what a guardian actively chose to retain. This guarantee is part of the onboarding agreement, not a footnote.

The platform is in active development. Built and production-ready today: the Child Consent Ledger; the QR/PIN check-in and attendance engine; the ratio monitor; the tuition billing engine (charge rail honest-off); the consent substrate with revocation and audit export; and the photography and yearbook bridge. In active development: the charge rail, live carrier delivery for communications, the licensing compliance binder-export UI, and the CACFP meal-count export. The best next step is a conversation where we show the current state honestly and discuss what early access looks like for your program.