A behaviour record follows a child. Build it as though it will be read in five years.
A behavior tracking app is not a productivity tool with children in it. It is a system that holds statements about named young people, statements that can shape how the next adult treats them before they have met. That is the frame worth keeping, and it changes the design more than any feature list. It also makes this a different problem from a parent teacher communication app, which carries messages rather than assessments.
What follows is what an observation has to contain to be worth anything, what an app can honestly measure, who is permitted to read it, and the question nobody builds for, which is when a record should stop existing.
See what an observation has to holdThe short version
Record episodes, not children, and be strict about who can read them.
An observation is something that happened at a time: what came before it, what the child did in plain observable terms, what followed, and how long or how often. A label attached to a person is none of those things, and it cannot be disproved by anybody who inherits it.
Access is the other half, and it is the half that gets treated as an afterthought. A record about a child that reaches the wrong adult is the failure mode that actually matters here. Everything about permissions should be decided before the first screen, because retrofitting access control onto a system that assumed everyone could see everything is not a small change.
What an observation has to hold
The structure that has held up in practice is to record what came immediately before, what the child did, and what followed. It is unglamorous, it takes slightly longer than typing a sentence, and it is the difference between a record that explains something and a record that accuses somebody.
Describe, do not conclude
Left the room is an observation. Defiant is a conclusion, and once it is in a system it is read as a fact by everyone downstream. The form should make the observable description the easy path and give conclusions nowhere convenient to live.
The adult response is part of the record
What the teacher or carer did next belongs in the entry. Without it, the record can never show that a strategy was tried and what happened when it was, which is the whole point of collecting any of this. It also keeps the record honest about the fact that two people were present.
Try it
What an observation should and should not hold
Tick the fields your form would have. The ones you leave out are the ones a reader six months from now will need most.
5 things to reconsider
- Without it the record says a child is difficult. With it, the record says what set the episode off, which is the only part anyone can change.
- The response is data too. A record that never mentions the adult cannot show that a strategy was tried.
- The only way to tell whether anything is improving. Impressions do not aggregate; counts and durations do.
- Attaches to the person rather than the episode, follows them between years, and cannot be disproved. Leave it out.
- Worth discussing, not worth storing as a field. Motive is inferred, and inferences harden into fact once they are in a system.
What the app can honestly measure
Frequency and duration. How often something happens, and how long it lasts. Those two aggregate meaningfully across weeks and can show whether anything is changing, which impressions cannot.
Severity scales are tempting and mostly noise, because the same incident scores differently depending on who is entering it and how their morning went. If you do use one, define each point on the scale in the interface at the moment of choosing rather than in a policy document, and expect the data to be comparable only within one observer.
Context is the field that earns its place and is always missing: which lesson, which time of day, who else was there. Behaviour clusters around circumstances far more often than it clusters around children, and an app that records the circumstance makes that visible. If your setting already holds timetable information, a class schedule app is where that context comes from rather than something to retype.
Who is allowed to read it
In a United States school, a behaviour record about an identifiable student is an education record, and FERPA sets the rules. The general position is that prior written consent is required before disclosure. The exception most schools rely on permits disclosure to other school officials, including teachers, whom the institution has determined to have legitimate educational interests, and the institution must use reasonable methods to ensure that school officials obtain access only to the records in which they have such interests.
That last clause is a software requirement, not a policy aspiration. An app in which every member of staff can read every child's history does not meet it, whatever the staff handbook says. Access has to be scoped, and the scoping has to be something the institution can describe.
Third-party apps are covered explicitly. A contractor or consultant can qualify as a school official where it performs a service the institution would otherwise use employees for, operates under the institution's direct control regarding the use and maintenance of records, and complies with the limits on redisclosure. If you are building something a school will use, you are that contractor, and those three conditions are things your app and your contract have to actually satisfy.
None of this is legal advice, and a school's own counsel or privacy officer decides what applies. Ask before you deploy, not after.
Parents, young children, and when a record should end
Parent access is where good intentions cause harm. Sharing the raw log with a parent in real time sounds transparent and frequently is not, because an observation written as a note between colleagues reads very differently to the person who loves the child. Decide what is shared, write it for that audience, and never let a parent see something a child cannot.
Custody arrangements are the specific case that breaks naive designs. Which adults may see a record is not always obvious, it changes, and getting it wrong is serious. This is fundamentally an identity question, so it is worth reading about who may see a child's record before designing accounts.
For younger children the privacy floor is different again. The COPPA Rule defines a child as an individual under the age of 13, and treats names, contact details, persistent identifiers and geolocation as personal information. A childcare app collecting daily observations about toddlers is squarely in that territory.
Then the question nobody builds: how long the record lives. A difficult term in year three should not be visible to a teacher in year nine by default. Retention is a feature, it is one of the few places software can protect the person it is written about, and it is almost always left out because nobody asks for it.
What each way of recording behaviour leaves you with
| Option | Structured episodes | Aggregates over time | Access scoped | Record can expire |
|---|---|---|---|---|
| Notes in a planner | No | No | whoever holds the book | when it is thrown away |
| Email between staff | No | No | No | No |
| Shared spreadsheet | if the columns are right | Yes | No | No |
| School information system module | Yes | Yes | Yes | per the school's policy |
| An app you build | Yes | Yes | Yes | Yes |
Building one around your own setting
Behaviour modules inside school information systems are built for reporting upward: counts, sanctions, a figure for a governors' meeting. Plenty of settings need the opposite, a record designed for the adult who has this child next lesson. Specialist provision, alternative education, and one-to-one support all end up keeping a parallel paper record because the system cannot hold what actually matters.
Newly is an AI app builder. You describe the app you want, including the observation format your setting already uses, and it builds and ships a real mobile app you own. Plans start at $25 a month, there is no free plan, and iOS builds ship through App Store Connect. It is not an education platform, it does not process payments, and it will not make a compliance decision for you. It is what you use when the module you have does not fit the children you work with.
Decide access and retention before anything else. They are the two things that are genuinely hard to change later, and they are the two that determine whether the app helps a child or simply follows them.
Questions people ask about behaviour tracking apps
What happened immediately before, what the child did in plain observable terms, what followed including the adult's response, and how long or how often. Labels attached to a child are not observations: they cannot be disproved, and every adult who inherits the record reads them as fact rather than as one person's impression.
Describe the record your setting actually needs
Write down what an observation has to capture and who is allowed to read it, and build the app around those two answers.
Start building