Cal Poly senior capstone with Calling All Kids · 2025–2026
Calling All Kids Parent Dashboard
Turning children’s simulated calls into a report a parent can actually understand.
- Node.js
- Express
- Flutter Web
- local CSV snapshots
- Mocha
- OpenAI API
not a diagnosis ♡
useful signals were hiding inside every call
Calling All Kids lets children ages two to six have simulated conversations with virtual characters. The calls created rich usage and transcript data, but parents had no calm, understandable way to see what those signals might mean.
Our six-person Cal Poly capstone team designed a standalone parent-dashboard prototype: a periodic, non-clinical snapshot of activity, temperament, moods, topics, and practical guidance that CAK's engineers could later integrate into their production system.
four parent-facing chapters from one call history
Activity
Call count, completion, duration, ratings, time-of-day patterns, favorite characters, and common themes make usage legible.
Temperament + archetype
Qualitative scoring maps concentration, energy, and sensitivity into a gentle animal archetype rather than a clinical label.
Moods + topics
Transcript analysis summarizes recurring emotional and conversational signals for the same reporting window.
Parent guidance
Conversation starters, daily strategies, and reframing prompts turn the report into something a parent can try.
from labels to little characters
making personality feel supportive, not clinical
Early explorations represented each archetype with a human child. We worried that a specific-looking child could feel too literal and invite a parent to compare that illustration directly with their own child, so the team moved toward animal characters instead.
The animal direction made the categories warmer, more playful, and less like a fixed judgment. I contributed to the team's archetype naming and design brainstorm; teammates implemented the mapping system.
parent guidance
turning a label into something useful
A score or archetype alone was not enough. The next question was: what does this mean, and what can a parent gently try?
I authored the source advice used in the app: conversation starters, daily strategies, ways to get back on track, and ways to reframe new challenges. Teammates wired that content into the interface.
The language stays explicitly non-clinical and avoids presenting a young child's behavior as a diagnosis or a permanent identity.
six people, one product
building it like a real product team
Six students built the prototype through seven Jira-tracked sprints. Work was divided by feature and bandwidth rather than formal titles, with dedicated meetings and separate Discord channels for the team, professor, and client conversations.
That coordination mattered because quantitative analysis, temperament, moods, topics, advice, and the dashboard evolved in parallel. When output contracts stopped matching the whiteboard plan, regular handoffs and integration work became as important as any individual feature.
- planJira estimates and sprint commitments
- buildindependently owned product pieces
- reconcileshared shapes, reviews, and handoffs
- presentclient, course, and final-capstone demos
a handoff-oriented prototype architecture
Flutter Web
Provides the phone-shaped parent experience and a development panel for selecting a child and running the pipeline.
Node.js + Express
Organizes routes, controllers, services, helpers, and report contracts around conventions CAK's engineers could integrate later.
Local CSV + analysis services
The handoff prototype reads anonymized local CSV snapshots rather than a database. Independent services produce usage, temperament, mood, and topic outputs from the selected calls.
OpenAI structured output
A direct HTTP wrapper calls gpt-4o-mini at low temperature with JSON Schema constrained output. Retry and graceful-degradation behavior were specified for the handoff rather than presented as production infrastructure.
Report assembler
Acts as the integration adapter: validates required inputs, normalizes divergent shapes, and builds the final external/internal payload.
Mocha + Chai + NYC
Runs 147 backend tests with 92.56% statement coverage across the reviewed working tree; 31 tests focus on my report seam.
one report, several pipelines
Quantitative activity, temperament, moods, and topics were developed in parallel. I owned the report-assembly seam: normalizing the different output shapes and restructuring them into the single parent-report contract.
At that boundary, missing upstream pieces fail loudly, while field-name and label differences are reconciled before they travel further through the system.
deciding when a report is ready
I wrote the reporting-logic specification around call-count windows, data quality, graceful degradation, retries, and score smoothing.
A full report waits for 20 calls. The design also proposed smoothing and requiring consecutive reports before visibly changing an archetype, so one noisy window would not produce an overconfident conclusion.
breaking dependencies at the seam
The original assembler reached directly into data files, networked services, and model calls. I applied Parameterize Method so it accepts completed pipeline outputs instead.
That refactor made the integration deterministic enough for 10 assembler tests and 21 final-report tests to run without mocks, data files, network access, or API keys.
making model consistency visible
On a separate, unmerged feature branch, I built Bucket Spread Testing: a Chart.js admin tool that repeats scoring and visualizes how often a child lands in the same archetype or temperament triplet.
Four charts, a plain-language glossary, run persistence, and a confirmation step make a fuzzy reliability question inspectable without presenting the tool as a shipped production feature.
product rules, integration, hardening, and parent guidance
I owned the report assembler and final report shape, wrote the reporting-logic specification, authored the source advice used in the app, and fixed integration problems across several team-owned services.
I also built the Bucket Spread admin visualization on an unmerged feature branch. The quantitative pipeline and archetype-mapping implementation were teammate work; I presented the quant work in the final demo and contributed to the group's archetype naming/design direction.
- Normalized real teammate output shapes into one header / external / internal / feedback contract.
- Applied Parameterize Method so 31 focused tests run without mocks, data files, API keys, or network access.
- Specified call-count thresholds, data quality, retries, smoothing, trends, and graceful degradation.
- Authored parent advice and helped keep the framing supportive, non-clinical, and reviewed by an external child psychologist.
- Built four Chart.js reliability views plus a glossary, run persistence, and a billed-call confirmation step.
results, with context
full-report threshold
The handoff specification waits for enough call history before presenting the full qualitative report.
my integration seam
The assembler and final-report flow run independently of model APIs, data files, and network access.
team process
Jira-tracked planning showed commitment and completion estimates converging over the capstone.
The project became most interesting where product care and engineering met: choosing language that would not overstate what a child's calls could tell us, giving parents a useful next step, coordinating six independently moving pieces, and then making the resulting report dependable enough to hand off. I would formalize the shared pipeline contracts earlier next time. NDA-sensitive Figma work and private client materials remain off this page.