Short answer: nursery software is not an attendance sheet — it is three separate ledgers kept in one place: the child’s day (attendance, sleep, meals, activities), pickup authorisation (who may collect the child) and billing (fees, extras, absences). When you evaluate a product, the first question is not how many screens it has but this: is pickup authorisation a dated record, does the daily report close in one tap, and are charges raised separately from payments? Those three eliminate most off-the-shelf packages in the first meeting.
Nursery software is not a smaller school system
The structure we described in school management software is built around lessons, grades and exams. A nursery has no grades; the day itself is the data: when the child arrived, how long they slept, what they ate, which activity they joined, nappy or toilet status. These records are operational rather than academic, and their real consumer is the parent, not the teacher. So the data model differs too: records belong to **a child and a day**, not to a lesson.
The second difference is age banding. A one-year-old and a five-year-old cannot share a screen: infants are measured in sleep and feeding intervals, the older group in activities and readiness. If the product cannot carry a different field set per group, teachers go back to a paper notebook — and nothing in that notebook ever reaches a report.
The most critical module is pickup authorisation
A nursery has exactly one irreversible mistake: handing a child to the wrong person. That is why authorisation must not be a free-text note but **a record carrying a date range** — a grandmother may be permanent, a neighbour only this week. At the door the system has to answer one question: may this person collect this child right now?
type PickupAuthorisation = {
childId: string;
personId: string;
from: Date;
until: Date | null; // null = open-ended
};
function canCollect(
childId: string,
personId: string,
at: Date,
authorisations: PickupAuthorisation[],
): boolean {
// Default NO: anyone not on the list cannot collect the child. The
// inverse (default yes plus a blocklist) means one empty field, one
// day, equals handing a child to the wrong person.
return authorisations.some(
(a) =>
a.childId === childId &&
a.personId === personId &&
a.from <= at &&
(a.until === null || at <= a.until),
);
}Two details matter. The default is **no**: anyone not on the list cannot collect. And authorisation is dated, so an expired permission closes itself instead of waiting to be deleted by hand. Who collected the child and at what time must be recorded — the answer to a parent asking the next day belongs in the system, not in a teacher’s memory.
A nursery product that keeps pickup rights in a "notes" field leaves the decision at the door to whoever happens to be on duty and what they remember. Modelling it as a person list plus a date range is not a feature to add later; it is a field to design up front.
Parent communication is the product
What sets a nursery apart in a parent’s eyes is visibility as much as the kitchen or the playground: knowing what happened during the day. The daily report (sleep, food, activity, photos) is not an optional module — it is what the institution delivers every single day. What works in practice:
- The report must close in one tap at the end of the day; if a teacher fills a separate form per child, reports stop being written by week three.
- Separate announcements from individual messages: if a group-wide notice and a message to one parent share a channel, parents read neither.
- Photo consent is held per child — one parent withholding consent must not block the group’s photos; that child is kept out of frame. For the messaging side see WhatsApp Business API integration.
- Emergency information (allergies, chronic conditions, medication) belongs pinned to the top of the child’s record, not in the report feed.
Health and allergy data is sensitive personal data; who can see it, how long it is kept and how photo consent is collected should follow the principles in GDPR/KVKK-compliant websites. This article is not legal advice — have your enrolment contract reviewed by an adviser.
Billing: charges are separate from payments
The most common mistake in fee tracking is creating the debt when the payment arrives. The correct order is the opposite: charges are raised for every child at the start of the month, and incoming payments settle them. We described the same distinction in HOA and apartment management software; a nursery adds these on top:
- Sibling discounts and corporate agreements — a discount should be a rule-driven field, not a number typed in by hand.
- Extras: transport, meals, late-pickup fees, summer term. Each is its own charge type.
- Absence policy: when does a fee drop and when does it not — the rule written in the contract has to exist in the software too.
- Online payment: sending parents a link raises collection rates; for the plumbing see payment integration.
Off-the-shelf or custom?
For most single-site nurseries a ready-made package is enough. Custom software starts to make sense when at least two of these three are true:
- You run several sites and enrolment, capacity and collections have to be seen centrally.
- Your pricing or absence rules are non-standard (corporate agreements, mixed half-day/full-day packages, seasonal rates).
- It has to talk to another system: accounting, transport tracking, e-invoicing. For that side see what API integration is.
A fourth question is the one most often skipped: can you export your data? If child records, pickup authorisations, billing history and daily reports cannot be exported, switching costs more than any licence fee. We broke the cost down in person-days in custom software cost; in a nursery the mobile side — the teacher’s tablet screen — is at least half the project, because if teachers do not use it, no record exists at all.
Conclusion
When choosing nursery software, check three things: is pickup authorisation a dated record, does the daily report close in one tap, and are charges raised separately from payments. With those in place the rest is reporting detail. If you are considering something built around your own institution, look at our custom software service or describe your process and request a quote.