Digital Sunset: When a Learning App Limits Its Own Screen Time

Almost every consumer app is engineered to take more of your time. Streaks, autoplay, infinite feeds, nudges to come back — the entire business model rewards minutes on screen. An education platform aimed at children cannot honestly run that playbook and then claim to care about learning. If the product’s incentive is to maximise screen time, “balance” is just a slogan.

PDP Shikshya, built by pdpspectra, takes the opposite stance and bakes it into two features. Digital Sunset actively limits how long a student can stay in the app and winds it down at night. Collaborative Trigger Routing detects when a student is genuinely stuck and pushes them off the AI and toward a human. Both are responsible-engagement-by-design: the platform is built to know when to stop. (For the full product context, start with the overview post.)

Digital Sunset: a daily cap and a nightly wind-down#

Digital Sunset is the screen-time pillar. It has two controls, both per-student, and both set by the student, a linked parent, or the student’s teachers — the same self/parent/staff permission model used across the platform.

• A daily limit in minutes. Zero means no limit; any positive number is a hard ceiling for the calendar day.
• A wind-down time — an “HH:MM” local time after which the app eases off for the evening.

When either is crossed, the app shows a gentle wind-down or lock screen rather than letting the session run on. The state the app reads back is simple and explicit: today’s minutes used, the daily limit, the wind-down time, whether it is currently locked, and the reason — limit or wind_down. There is no ambiguity about why the screen went quiet.

Counting minutes on the box, not with a tracker#

The mechanism behind the cap is deliberately low-tech and private. While the app is open and focused, it sends small heartbeats of active minutes. The backend accumulates them per calendar day in a per-student log. A single heartbeat is clamped — no more than fifteen minutes can be added at once — so a backgrounded tab or a clock glitch cannot inflate the tally. Each day gets its own row, keyed by ISO date, and the running total is what the limit is checked against.

Crucially, there is no third-party usage tracker involved. The minutes are computed and stored on the same box that runs the school’s tenant — the same on-prem-friendly posture the platform applies to student data and the curriculum RAG. A student’s screen-time history never leaves the school’s own data store. Parents and teachers can review a rolling seven-day view of daily minutes, so wellbeing is a shared, visible conversation rather than a silent count.

The point of all this is not to punish usage. It is to make the app a tool a student picks up, uses, and puts down — not an environment they live in. An education product that respects a child’s evening is making a statement about what it is for.

It is also worth noting what the heartbeat measures and what it ignores. It counts active, focused in-app minutes — time the student is actually present in the app — not wall-clock time with a tab left open. A session abandoned on a windowsill does not quietly drain the daily allowance, and a single heartbeat is capped so no one moment can dominate the count. The result is a tally a parent can trust: when it says 78 minutes, the child spent roughly 78 minutes learning, not 78 minutes with the screen idling. Honest measurement is the precondition for an honest limit.

Collaborative Trigger Routing: knowing when to hand off to a human#

Screen-time caps handle quantity. Trigger Routing handles quality — specifically, the moment when more time with the AI stops helping and a person needs to step in.

Inside the Socratic tutor, every student message is checked against struggle markers — phrases like “I’m stuck”, “I don’t get it”, “I give up”, plus Nepali cues such as thaha chaina and garna sakina. A struggle increments a per-session struggle streak and logs a struggle event; a message that moves forward instead resets the streak and logs an attempt. This is the same telemetry that powers Proof-of-Thought on the teacher dashboard.

The routing rule is blunt on purpose: when the struggle streak reaches three, the session is marked escalated, an escalation event is written once, and the tutor itself stops trying to be the only answer. Instead of generating yet another guiding question into a wall, it surfaces a suggestion to bring in a teacher or a peer study buddy. The escalation fires once per session — it nudges toward a human, it does not nag.

What the human side can do#

On the teacher’s dashboard, an escalated student is flagged for attention and floats to the top of the roster. From there the teacher has two concrete escalation actions, not just an alert:

• Route-to-review logs a note on the student’s record and notifies both the student and their parents that an in-person review of recent work has been requested. The struggle leaves the screen and becomes a real conversation.
• Peer study group spins up an actual group chat with the flagged student (or several), so the teacher can coordinate a peer study session immediately.

This is the philosophy made operational: the AI is good at coaching a student through a problem, but when a student is genuinely stuck, the right move is a person — a teacher who can sit with them, or peers who can work alongside them. The platform treats reaching that limit as a feature, not a failure.

The threshold is also tuned to avoid crying wolf. A single “I don’t get it” does not trigger anything — the streak has to reach three consecutive struggles in one session, and any forward step resets it to zero. That means the escalation only fires for a student who is genuinely and repeatedly stuck, not one having a normal wobble mid-problem. And because it fires once per session and not again, a teacher’s attention is spent on real signals rather than a stream of false alarms. Restraint on the alerting side is what keeps the human escalation worth acting on.

A worked example: an evening with the cap on#

Picture a student whose parent has set a 90-minute daily limit and a 21:30 wind-down. Through the afternoon, the app sends heartbeats while it is open and focused; each one adds a few minutes to today’s log, never more than fifteen at a stroke. By evening the student has used 78 minutes — the dashboard’s Digital Sunset card shows the running tally against the limit, so there is no surprise. They push through to 90 and the app shifts to a gentle wind-down screen with the reason shown plainly as limit. Even if they had minutes to spare, once the clock passes 21:30 the same screen appears with the reason wind_down. Either ceiling is enough.

The next morning the counter is a fresh row for the new date; nothing carries over, and the seven-day view lets the parent and the class teacher see the week’s pattern — a heavy Sunday, a light Wednesday — and adjust the limit together if it is too tight or too loose. Because the wind-down compares against the local evening time, an after-21:30 lock only applies in the evening, not at sunrise. The whole system is a handful of integers and one time string per student: easy to reason about, easy to audit, and impossible to quietly game.

Why “knowing when to stop” is a design discipline#

Responsible engagement is easy to put on a marketing page and hard to put in a codebase, because it almost always works against engagement metrics. A daily cap reduces minutes. A wind-down screen sends a kid to bed. An escalation hands a student off to a teacher instead of keeping them in the chat. Every one of these is the platform choosing the student’s interest over its own usage numbers.

That is the through-line of both features. Digital Sunset limits the app’s own screen time; Trigger Routing limits the app’s claim on a struggling student. For a school running PDP Shikshya as its management and learning platform, these are the mechanisms that let it answer the parent who asks “is this just another thing keeping my child glued to a screen?” with something concrete: no — it is built to put itself down, and to send your child to a human when that is what they need.

That kind of restraint does not happen by accident. It is an AI implementation decision, an Operational Automation decision, and a values decision, all made at the code level — which is exactly where they have to be made to be real.

---

Designing software that optimises for the user’s wellbeing instead of their attention? That restraint has to be engineered in. Talk to our team at pdpspectra.com/#contact, or see Digital Sunset and Trigger Routing in action at pdpshikshya.com.