0 → 1 CONCEPT · MOBILE · INDIA · SCHOOL TRANSPORT

GHANTI rings only when it matters.

Most products in this category answer "Where is the bus?" Repeated irrelevant alerts had trained me to swipe those answers away, and public reviews indicated similar trust problems. GHANTI is a child-first tracking concept built on one rule: a signal is sent only when it is true for this child, this parent, this moment. It also introduces a signal none of the nine audited products documented: the bus left, but your child wasn't confirmed aboard.

Type
Independent product concept (0→1)
Role
Research, strategy, product design
Method
Autoethnography + evidence audit
Platform
Mobile · Android & iOS
01 — The observation

"The app tracks the bus.
But I'm not raising a bus."

Field note · designer as parent-user of a live tracking app · 2026

I am the user of this product category. My child rides a school bus tracked by a third-party app, and every notification was about the vehicle: it fires on holidays, during bandhs, on days my child is home on leave — and it said nothing the day it mattered. In my routine, repeated irrelevant alerts had trained me to ignore a channel that should have carried the highest-stakes information. That observation became this product.

ChallengeParents send children on school buses every day with no real-time awareness. When something goes wrong — a late bus, a missed stop, an absent child — parents find out through WhatsApp chains and missed calls. The answer to a simple question does not exist.
ApproachDocumented my own commute routine through autoethnography, audited 9 existing tracking products, mapped the emotional arc of a school morning, and designed a signal engine that speaks only when it needs to — and stays silent the rest of the time.
ResultGhanti: a child-centric bus tracking app built around one principle. Not more data — the right signal at the right moment. Four prototyped flows that cover the full commute lifecycle, from departure to arrival to exception.
02 — The problem

Three questions I needed answered. The products I audited did not answer them together.

"Where is the bus?" was never the parent's question — it's the sensor's answer. The parent's real questions are about the child, the day, and the walk to the stop. India runs on shared drop points, not doorstep drops: timing that walk is the highest-frequency job, and none of the audited products served it directly.

Presence
"Is my child actually on it?"
Tracking begins at boarding, not ignition. A bus that departs without the child must produce the loudest signal in the system — today it produces silence.
Context
"Is today even their day to be on it?"
Holidays, sudden closures, applied leave — the context exists, but it lives in the school's separate app and never gates the tracking pipeline.
Timing
"When exactly do I walk to the stop?"
Straight-line distance lies — buses detour into unseen streets for other children's stops. The real signal is stops-before-mine and route-aware ETA.
03 — Research

Living the problem, then auditing the market's claims against the field.

Primary research was autoethnographic — I logged my own daily use of a live tracking app as structured pain points. Then a desk audit: nine competitor products, every capability claim verified against vendor pages and store listings, and — more importantly — against documented field behavior. The gap between the two is the insight.

"It tracked the completely wrong bus… It is actually better to NOT have them at all. At least I won't have the wrong information."
Verified parent review · SafeBus, Play Store
The app reported a child boarded when boarding never occurred — the exact inverse of the one alert that matters.
Parent review · App Store, documented
"Sometimes it won't show anything, then it will start showing up backdated data" — stale streams presented as live truth.
Verified parent review · Play Store
My own log: notifications on holidays, on bandh days, on leave days my child never left home. Every alert generic, every alert ignored.
Primary · autoethnography log, 2026

Six insights came out of synthesis. The three that carry the product: parents ignore the app that watches their child (noise has burned the channel), the app makes the parent do the math (a live dot is a question, not an answer), and when blind, it pretends to see (GPS drops produce frozen dots, not honesty — parents discover the lie at the roadside).

04 — Competitive whitespace

Every ingredient exists somewhere. Nobody cooks the meal.

I audited nine products against the capabilities that matter to a parent — every cell verified from the vendor's own pages, official store listings, or documented user reviews. Proximity alerts exist (fixed radius). ETA exists (bus-level). RFID boarding exists (hardware add-ons). Nobody wires them into a pipeline gated on the child. The green rows are GHANTI's territory — no competitor documents a single one.

scroll to compare all nine products →
CapabilityChakraviewSkoolBeepVersionXmyskoolbusTrackoSafeBusDhundhooGHANTI
Live map trackingroute-aware
not a raw dot
Proximity alert fixed radius or stop-based, vendor-set✓ 1–2 km✓ 5 min
ETA shown bus-level, straight-line
Route + ordered stops visible±±±
Boarding detection RFID / NFC / attendant± fleet tier± claimed● multi-signal
Custom proximity alarm parent-set, in stops or minutes
Route-aware ETA "N stops before yours", detours + dwell time
"Bus left — child NOT aboard" alert± marketing claim
Context-aware notification control holiday, closure, leave → designed silence± leave gates driver only
Honest degraded state admits GPS loss; no frozen or backdated dots
verified from vendor / store listing± partial, tier-gated, or unverified claim not documented (never claimed as "doesn't have") designed in GHANTI

Two more audited (eTechTracker, Track School Bus) fell out of the matrix on basics: broken login per reviews, stale updates — and one ships a child-location app whose store label reads "data isn't encrypted." Field behavior gap documented in Research above; full source log in the walkthrough.

05 — Personas

Two parents, one child, opposite mornings.

Both personas are built from my own household and the parents at a shared drop point (small n — treated as proto-personas, not validated archetypes) — composites, not fabrications, and flagged as such in the assumption register. The child is deliberately not a persona: Aarav is the subject of every signal, but the phone in hand belongs to a parent.

Primary · at the stop
The Stop-Timer
"I set a 7:35 alarm on my phone because the app can't tell me when to leave the house. I built the feature it doesn't have."
Reality
Walks to a shared drop point twice a day — the stop is three streets away, decided by the driver's route, not by her
Times the walk by instinct and a self-made alarm; stands on the road when instinct fails
Needs from GHANTI
"Ring me 2 stops before" — an alarm in stops or minutes, route-aware
Boarding confirmation before anything else pings
Secondary · away from home
The Remote Watcher
"I'm in a standup when the bus reaches home. My mother does the pickup — I just need to know it ended well."
Reality
At the office through both bus windows; a grandparent or neighbour covers the stop
Gets the same notification flood as the at-home parent — reads none of it during work
Needs from GHANTI
Exactly two signals a day: boarded safely, arrived safely — and any exception, loudly
Second-guardian access without sharing her own login
06 — Design principles

Four rules the product cannot break.

Each one is a direct answer to a research insight — and each one costs something. A principle that costs nothing decides nothing.

P·01
Every signal is earned.
Each notification fires only when its required inputs meet the signal rule. The cost is that GHANTI speaks less than every product in the audited set—but that scarcity is what gives each ring its meaning.
P·02
The child is the unit, not the bus.
Tracking begins when my child boards and ends when they're back with me. The cost: presence detection is genuinely hard (see the threat model in A3) — GHANTI treats it as confidence, never as a binary lie.
P·03
Silence is designed, not defaulted.
A quiet day shows why it's quiet. The cost: we build screens most apps never bother with — the holiday state, the leave state, the nothing-to-say state.
P·04
Honest when blind.
When GPS drops, GHANTI says what it last knew and when — never a frozen dot pretending to be live. The cost: admitting failure in a category that markets certainty. It's also the moat.
07 — The concept

The Signal Engine: every signal earns its interruption.

GHANTI inverts the category's architecture. Competitors broadcast vehicle state and let parents filter; GHANTI filters first and treats silence as a designed state. Different signals fire on different rules — not every notification passes through the same conditions. Three inputs govern what each signal knows: context, timing, and presence. One honesty layer sits above all of them.

Input 1 · Context
Is today their day?
School calendar, sudden closures, one-tap "not going today." Works standalone — silence never depends on the school's cooperation. School-app sync is the upgrade, not the requirement.
Input 2 · Timing
When do I walk?
Stops-before-mine + route-aware ETA including dwell time. The alarm is set in stops or minutes — matched to the shared drop-point reality of Indian streets, not doorstep assumptions.
Input 3 · Presence
Is this about my child?
Signals begin when this child boards — multi-signal confidence (RFID scan + attendant confirmation + stop geofence), never a single swipe. Bus departs without the child → the alert none of the nine audited products documented.
Across all inputs
Honesty layer
When GHANTI can't see, it says so: "Last confirmed at Stop 6, 4 min ago." A degraded state shown honestly beats a confident lie — trust is the actual product.
Silence is a feature. On a holiday, GHANTI's home screen says why it's quiet — "No school today. GHANTI is silent." A parent who understands the silence trusts the ring.
08 — Information architecture

Four tabs. The engine decides what they say.

The IA is deliberately shallow — a parent mid-walk gets one thumb and three seconds. Everything orbits Today, where the live map lives; the other three tabs exist so Today can stay almost empty.

Todayhome · the only daily screen
Current signal state (or designed silence)
Stops-before-mine + walk timer
One-tap "not going today"
Exception alerts live here
Routethe reference surface
All 12 stops, scheduled vs usual
Morning / afternoon switch
Crew and vehicle continuity
Per-stop reliability history
Circleconsent-gated social
Aggregate counts, no identities
Mutual-consent families at your stop
Relayed messaging, no numbers
Presence sources & data controls
Calendarthe context input's home
School calendar + closures
Leave marking & history
Holiday quiet-days preview
School-sync status (when tied up)
09 — Journey

One school morning, minute by minute.

Mapped from my own mornings before designing a single screen. The old-world emotional line dips at the same two points every day: the guess (when do I leave?) and the gap (did he actually board?). GHANTI exists to flatten exactly those two dips.

scroll through the morning →
06:45 · Prep
Is today a bus day?
Old world: check two apps and a WhatsApp group. GHANTI: Today screen answers in one glance — or is already quiet, with a reason.
Anxiety: low → none
07:30 · The guess
When do I leave the house?
Old world: a self-made 7:35 alarm and instinct. GHANTI: "3 stops before yours · walk in 6 min" — the alarm the parent used to build by hand.
The first dip, flattened
07:44 · The walk
Three streets, no jog
Route-aware ETA absorbs detours and dwell time. Arriving 90 seconds early instead of nine minutes early sounds small; twice a day, every day, it isn't.
Calm, boring, correct
07:52 · The gap
Did he actually board?
Old world: the app goes quiet exactly when it matters. GHANTI: "Aarav boarded · 2 sources" — or the loud exception no competitor sends.
The second dip, flattened
08:20 · Release
Arrived. Phone away.
One arrival signal to both parents — the Remote Watcher's entire daily need — then GHANTI has nothing more to say until the afternoon.
Trust compounds daily
10 — Key flows

The happy path, and the path that matters more.

Two flows define GHANTI. The morning flow shows how context, timing and presence govern different moments; the exception flow shows why presence had to come first in the architecture — without it, the "not aboard" alert is undetectable.

Flow 01 — Morning pickup, gates in sequence
Every box the signal passes is a chance to stay silent. Most mornings, most boxes do.
Bus starts route
Nothing reaches the parent yet — ignition is the bus's business, not theirs.
CONTEXT INPUT · School day? Not on leave?
Fails on holidays, closures, or a marked leave → the whole day stays silent, with the reason shown.
TIMING INPUT · Bus N stops away from yours
Route-aware countdown against real stop order and dwell time. Alert fires when walk time matches bus proximity.
RING — "walk now, 2 stops away"
The single loud moment of the morning. It fires so the child reaches the stop before the bus does.
Parent walks child to stop
The app goes quiet again. Nothing to say until the bus arrives.
PRESENCE INPUT · Bus at stop, boarding window opens
GHANTI arms itself for one child at one stop. An RFID scan and attendant confirmation establish sufficient confidence that Aarav boarded — a quiet state change, not a notification.
Silence until arrival
Next signal: "arrived at school" — then nothing until the afternoon.
Design note: the ring fires before boarding so the parent can act on it. Every other step is a silent state change on Today — visible if you look, nothing if you don't.
Flow 02 — The exception: bus leaves, child not aboard
The flow no competitor has, because no competitor tracks presence. This is where multi-signal confidence earns its complexity.
Bus departs the stop
The departure event triggers a presence evaluation for every child expected at this stop.
Presence check — no scan, no attendant, no geofence
All three sources come back empty for Aarav. No source confirmed boarding; confidence remained below the alert threshold.
Confidence window — 60 seconds
Late card-swipes happen; an instant alert would cry wolf. The window absorbs them.
LOUD ALERT — "Aarav wasn't confirmed aboard"
Absence of signal ≠ confirmed absence — but it demands immediate attention. Requests the highest notification priority permitted by platform settings and guardian consent. This alert is the reason the others earned the right to be rare.
Parent resolves
"Aarav is with me" silences the day instantly — or one tap calls the bus attendant.
Context input closes the day
The resolution feeds back into the context input — no more pickup signals today.
The 60-second window was the hardest call in this flow — instant alerts produce false alarms from late card-swipes; long windows waste the minutes that matter. Sixty seconds is a stated assumption to be tuned in a pilot, not a truth.
11 — Structure before style

Lo-fi: what earns the first screen?

Three layouts for Today, evaluated against one scenario: it's 7:38, the parent has one thumb free and three seconds. The map — every competitor's hero — lost immediately. A map is a question; the parent needed an answer.

Option A — raw map, dot only (the category default). Rejected: a bare dot makes the parent do the math.
Option B — feed of events. Rejected: chronology is not urgency; the newest item is rarely the most important.
Option C — answer card leads, stops below. ✓ Chosen — then corrected: the map came back as the canvas beneath it.

Wireframes — Option C, resolved.

Four screens carry the product. Every layout decision below is a constraint, not a preference: one primary action per screen, a single answer above the fold, and nothing critical communicated by colour alone.

status · signal sources
1
CHILD + TRIP CONTEXT
2
THE ANSWER — stops before yours + walk time
3
ORDERED STOPS · mine marked
4
MAP — route with detours, answer sits over it
Today · on the way
1 Whose trip, so a two-child parent never mis-reads. 2 The answer, biggest thing on screen. 3 Stops in order — the walk-planning surface. 4 Map as an inset here — the decision I later reversed, once it was clear the map should be the canvas rather than a card.
status · quiet
CHILD CONTEXT
1
SILENCE, WITH ITS REASON
(holiday name / leave marked)
2
PRE-EMPT TOMORROW — one tap
Today · quiet day
1 The screen most apps never design. Silence must be legible, or it reads as a broken app. 2 The only action worth offering on a day with no bus.
status · live
1
EXCEPTION — plain-language headline
2
WHAT WE CHECKED — the evidence list
3
RESOLVE — primary: "with me"
4
SECONDARY — call attendant
Exception · not aboard
1 No jargon, no error code. 2 Evidence builds trust in a scary claim. 3–4 Two actions only — resolve or escalate; nav bar hidden so nothing competes.
status · degraded
CHILD CONTEXT
1
"WE CAN'T SEE THE BUS"
2
LAST CONFIRMED — stop + timestamp
3
WHILE BLIND — estimate window, escalation clock
Today · degraded
1 Admission first, before anything else. 2 The last thing we actually knew, timestamped. 3 What happens next, so blindness still has a plan. No map — a frozen dot is the lie we're avoiding.
Structural rules applied across all four
One answer above the fold. A parent mid-walk gets one glance — the primary answer never shares the top of the screen with a chart, a map, or an ad.
One primary action per screen. Secondary actions are visually quieter and never adjacent to the primary — no mis-taps on a walking phone.
Bottom-anchored actions. Everything tappable sits in the lower third: one-handed reach, and reachable for smaller hands and less steady ones alike.
Never colour alone. Every state carries an icon, a text label, and its own tone — so the design survives colour-blindness, sunlight, and a phone held at arm's length.
The nav bar disappears in exceptions. When the "not aboard" screen fires, browsing is not the job — resolving is.
12 — Sensory design & accessibility

The phone is in a pocket. It still has to speak.

A parent walking to a stop on an Indian street is holding a bag, a child's hand, or both — screen-first design fails them. So the signal layer is designed for ears and skin first, screen second: each signal type gets its own tone and haptic pattern, and the walk tone encodes proximity in its tempo. You learn the language in a week and stop looking at the phone.

Signal
Tone & haptic
Why this shape
Boarded safelyConfirmation
Two-note rise · single soft buzz
Rising intervals read as resolution across cultures. Quiet enough to ignore in a meeting — this is reassurance, not a summons.
Bus approachingWalk now
Pulse tempo rises with closeness
The proximity is the tone. Slow pulse at 3 stops, faster at 2, urgent at 1 — a parent can time the walk without unlocking anything, or seeing anything.
Not aboardException
Distinct 3-burst · long haptic · highest permitted priority
Shares no motif with any other signal — it must be unmistakable at the bottom of a bag. Designed as a critical-alert candidate — uses the highest notification priority available, subject to platform permissions and guardian consent.
Signal lostDegraded
Low flat double · no haptic
Deliberately unremarkable and flat — a degraded state must never sound like news, or parents will act on nothing.
Quiet daySilence
Nothing at all
The absence is the design. Silence is only trustworthy if it is total — one stray ping on a holiday undoes months of earned trust.

Tone design would be validated with parents before build — the tempo mapping and the burst pattern are hypotheses, not proven audio ergonomics. Every tone is also user-testable against the one question that matters: can you tell them apart without looking?

Every signal on three channels
Sound, haptics, and screen carry the same message independently. A deaf parent gets the pattern in their palm; a blind parent gets it in their ear; a parent in a loud market gets it on the glass. No signal depends on any single sense.
Built for the whole household
Grandparents do a large share of Indian school pickups. Base type is 17px with a full dynamic-type scale, targets are 48dp+, and the primary answer is a short sentence — not a dashboard, not an abbreviation, not a map you must interpret.
Contrast for sunlight, not for screenshots
The light palette clears WCAG AA at minimum, AAA on the primary answer text. Chosen over a dark UI deliberately: this app is used outdoors at 7am and 3pm, by mixed ages, on cheap screens with worn coatings — where light-on-dark loses first. Colour is held in tokens rather than in screens, so a palette change can be re-tested against these thresholds instead of quietly breaking them.
Warm paper, not alarm red
Safety apps default to sirens — red, black, urgent chrome, a permanent state of alert. That is exactly wrong here: a parent opens this twice a day, every day, and an interface that always looks like an emergency cannot signal a real one. GHANTI reads as calm paper so that its one loud moment has somewhere to stand out from.
Platform-native, both stores
Android and iOS: TalkBack and VoiceOver labels on every state (including silence — "no school today, GHANTI is quiet"), system font scaling honoured to 200%, reduced-motion respected, and haptics mapped to each platform's own vocabulary rather than a custom rumble.
13 — The product

Designed, built and prototyped in Figma.

Thirteen screens across four flows, assembled from a component library built on themeable variables. What follows is the final prototype — assembled from a component library, not drawn screen by screen.

GHANTI Today screen: map with route and a bottom sheet reading three stops before yours
Today · sheet collapsed. The map is the canvas, drawn as the real route including its detours — with a faint straight line beside it showing the shortcut every other app implies. The answer rides above it in a sheet.
GHANTI Today screen with the sheet dragged up revealing the full ordered stop list
Today · sheet expanded. Same screen, one drag. The full ordered stop list appears without leaving the map — position in the list is the information.
The correction

My first version demoted the map a tap deeper. That was wrong — and fixing it made the argument stronger.

The research said a raw dot with straight-line distance lies. I over-read that as "hide the map," which threw away the one thing parents open the app for. The real fix was to keep the map primary and repair what was broken about it: draw the actual route, make the detour visible, and put the answer on top of it. The dashed ghost line on the screen above is that whole argument in one detail — the lie and the truth, side by side.

The states that define it

Alert screen: bus left Stop 8, Aarav is not aboard
A signal none of the nine audited products documented. Presence-gated, loud by design, evidence listed. The highest notification priority available after explicit guardian consent.
Quiet day screen: no school today, GHANTI is silent
Silence, explained. The screen most apps never design. A parent who knows why it is quiet trusts it when it rings.
Degraded state: we cannot see the bus right now, with last confirmed position
Honest when blind. Last confirmed stop and timestamp, an arrival window from route history, an escalation clock. No frozen dot.
Walk alarm customisation screen with stops and distance options
The alarm, on the parent's terms. By stops or by distance, each option priced in minutes of notice — recalculated daily from the real route, never a fixed radius.

Reaching a human, and the feature I rebuilt

Contact screen listing bus attendant, driver and school transport desk
Escalation with a safety opinion. The attendant comes first — they can physically walk the aisle. The driver is deliberately marked unavailable while moving: a child-safety app should not encourage calling someone who is driving. SOS needs a three-second hold so it cannot fire from a pocket.
Stop Circle screen showing aggregate counts and consent-gated families
Stop Circle — the feature I killed and rebuilt. A browsable roster of every child and where they get off would be a map to those children. So: counts for everyone, identities only inside a mutual-consent circle at your own stop, messages relayed with no numbers exchanged. The screen ships its own rationale.

The two reference tabs

Route tab showing all stops with scheduled and usual arrival times
Route. The map answers "where is it now"; this answers "can I trust it". Every stop carries scheduled vs usual — "usually 07:49 · +2 min" — so the route-aware ETA is auditable rather than magic. The crew card names the attendant and notes the same crew since June, because continuity is what parents actually judge.
Calendar tab listing upcoming days as school day, holiday or marked leave
Calendar — "When GHANTI will be quiet". The context input made inspectable: every silent day ahead, with its reason. Leave marked here works even if the school never syncs, so silence never depends on someone else remembering.

Designed for when things aren't working yet

Waiting state: route 12 starts at 07:10
Before the route starts. "Nothing to watch yet — you can close the app." An app that tells you to put it down is one you start trusting.
Loading state with dimmed map and skeleton rows
Loading, honestly. "Waiting for a second source to confirm. GHANTI will not show a position it cannot verify." The trust rule holds even in a skeleton.
Empty Stop Circle state explaining the consent model
Empty circle. The empty state does the teaching: three families use your stop, and we will not show you who — until you both agree.
14 — Flows & prototype

Four flows, wired end to end.

The screens run as a prototype, not a gallery: sheet drags smart-animate between states, screens push, tabs dissolve, and loading advances on its own timer.

Flow 1 — Morning happy path
Context confirmed
School day. Child expected. Bus started. Input 1 passes — still nothing to say.
Route active
Live map shows real route polyline, ordered stops, walk time. Silent state.
Proximity threshold
Bus N stops away. Walk time matches. Input 2 fires.
Walk alert rings
"Walk now — 2 stops away." Fires so the child reaches the stop before the bus does.
Presence confirmed
Bus at stop. Boarding window opens. Scan + attendant confirm child aboard. Quiet state change.
Silent until arrival
Nothing more. Arrived at school — then nothing until the afternoon.
Flow 2 — Exception: child not detected aboard
Context input
School day. Child marked present. Bus departed stop.
Presence input fails
No boarding signal after 60s window. Confidence falls below threshold.
Alert fires
"Aarav may not be aboard." Loud by design. One tap to confirm or dismiss.
Contact surface
Driver, attendant, school — all reachable from one screen, no digging.
Resolution
Parent confirms child is safe. Log closed. No further noise.
Flow ends earlier than Flow 1. Fewer steps in a worse situation.
Open the source

Everything above lives in one Figma file.

Thirteen screens, twelve components, 34 colour tokens across four theme modes, and four flows wired end to end. The file opens on a START HERE banner; each flow sits in its own labelled section, and the prototype runs from the ▶ button inside Figma.

Open the Figma file Components, variables and flow sections are named and organised — the file is meant to be read, not just looked at.
15 — Problems → solutions

Every pain point, answered — or honestly deferred.

The eight pain points from my audit and personal experience, traced to the exact mechanism that answers them and where it lives in the design. Traceability is the case study — if a pain has no answer, it says so.

The pain (from research)
What GHANTI does about it
Notifications are time-generic — fire on the driver's schedule, not the bus's position.
Every timing signal is computed from route position and dwell time, never from clock triggers.→ Signal Engine · Timing input · State 01
No custom proximity alarm — parents build their own with phone alarms.
"Ring me N stops / N minutes before" — the alarm parents were already improvising, made native.→ Route surface · State 01
Route and stop order invisible — parents can't plan the walk.
The map draws the real route polyline including detours, with ordered pins and yours marked — and a faint straight line beside it showing the lie other apps tell. The answer rides in a sheet above it.→ Map surface · State 01
Shared drop points unmodeled — apps assume doorstep drops.
The stop is a first-class shared object; walk-time to it drives the timing gate. Flagged honestly as assumption A1 pending field cases.→ Persona: Stop-Timer · Assumptions A1–A2
Fires on holidays and closures — the app doesn't know the calendar.
Context input silences the day and says why. Works standalone via one-tap "not going"; school sync is the upgrade, not the dependency.→ Signal Engine · Context input · State 02
Fires when the child is on leave — leave lives in the school's separate app.
Leave marked inside GHANTI suppresses all commute notifications for that day; no dependence on school enforcement (assumption A4, verified for my school).→ Context input · Calendar surface
The bus is tracked, the child is assumed — no "not aboard" alert exists.
Presence input makes the category's missing alert detectable — multi-signal confidence, loud by design, with a 60s window against false alarms.→ Presence input · Flow 02 · State 03
When blind, it pretends to see — frozen dots, backdated data, wrong buses.
Degraded state is designed: last confirmed truth, stated blindness, arrival window from route history, escalation after 10 minutes.→ Honesty layer · State 04
16 — Stated assumptions

What I know, what I assume, and how I'd find out.

A concept is only as honest as its assumption register. Nothing here is silently assumed — each open item is the first research task of a live pilot, not a footnote.

ID
Assumption
Status
A1
The walk to a shared stop is a real, frequent parent job. Grounded in my own routine + written stop policies at six school chains.
🔶 Open — needs 5–10 field cases across schools/cities
A2
Walk time to a shared stop is predictable enough to drive a timing gate. The walk-time estimate assumes consistent adult pace and a known stop location. Variables like traffic, weather, and a child's pace are not modelled.
🔶 Open — needs field measurement across stop types and demographics
A3
No single boarding signal is truth. Proxy swipes, hurried attendants, nursery kids who can't self-manage cards, lost/cloned credentials — presence must be multi-signal confidence with honest confidence states.
✅ Reasoned via threat model; field frequencies unknown
A4
Schools don't reliably enforce leave-marking today — which is why the context input must work standalone, without school cooperation.
✅ Verified for primary school; breadth unverified
A5
Notification fatigue is category-wide, not just mine. Review complaints align; small n.
🔶 Partially evidenced — needs 3–5 parent testimonies
17 — Reflection

What building GHANTI taught me.

Being the user is a method — with a discipline.
Autoethnography gave me pain points no interview would surface. The discipline is separating "verified" from "my experience" — the assumption register exists so my convenience never masquerades as evidence.
The absence of a signal is a design surface.
The quiet screen and the blind screen took more design thinking than the tracking screen. Deciding when not to speak — and saying why — is where this category's trust was lost.
Whitespace comes from field behavior, not feature lists.
On paper, competitors have everything. The gap only appears when you audit claims against documented reality — offline weeks, wrong buses, backdated dots. The feature list is not the product.
Appendix · build artefacts

Not part of the argument — the file underneath it. Included because the screens above were assembled from a system, not drawn one by one.

12 components
Button, Tag, Stop Row, Signal Card, Sense Strip, Map Surface, Map Control, Aboard Count, Sheet Grabber, Status Bar, App Header, Nav Bar — variants and usage rules written into each description.
34 tokens · 10 text styles
Grouped by role, not hue — including the ten map-surface tokens, so the map re-themes with everything else. Every fill, stroke and label is variable-bound, so the contrast work in §12 can be re-verified whenever a palette changes.
10 icons · 4 flows
SF-Symbols-style at 24px. Active tabs carry colour, stroke weight and label weight together — the never-colour-alone rule applied to the chrome as well as the content.
Colour · grouped by role, not by hue

Nothing is named for what it looks like. A token is called alert/soft-bg, never red-50 — so a palette can change without every name in the file becoming a lie. All 34 live in four theme modes; the screens hold no hex at all.

Surfacespage · card · sunken · shell
Paper, not grey. The app is read outdoors.
Textprimary · secondary · muted
Three levels only — more invites hierarchy nobody reads.
Confirm · accentsolid · soft-bg · soft-fg
The only saturated green. Spent on actions, never decoration.
Attentionsolid · soft-bg · soft-fg
Brass, for states that need noticing but not panic.
Alertsolid · soft-bg · soft-fg
Appears on exactly one screen. That is the point.

Four theme modes, one file. Warm paper is the default; a cool-slate alternate proves the swap works; two slots stay open. Contrast is re-verified per palette — §12's AA/AAA thresholds are a test, not a claim.

Type · three families, three jobs

Fraunces carries the answer — the one thing a parent reads at a glance. Work Sans carries explanation, because it stays legible small and at speed. DM Mono carries system truth — times, sources, tone labels — so machine-reported facts never wear the same clothes as human sentences.

Display/AnswerFraunces SemiBold · 30/36 · −1%
3 stops before yours
Title/ScreenFraunces SemiBold · 19/24
Reach someone
Body/Large · baseWork Sans Regular · 17/26
Walk in 6 min · ETA 07:50
Body/SmallWork Sans Regular · 13/20
Ganesh Chaturthi — from your school calendar.
Mono/LabelDM Mono Medium · 11 · +8%
WALK TONE · TEMPO RISES AS STOPS FALL

17px base, not 15. Set for a grandparent at a stop in sunlight, not for a portfolio screenshot — and the whole ramp honours system font scaling to 200%, so it grows with the reader's own setting rather than resisting it.

Parents don't need bus tracking.
They need the truth about their child.

Four prototyped flows available in the Figma file, wired end-to-end from the prototype button.