Inspiration

Finding a potential playmate is only the beginning. Parents also need to agree on a time, respond to requests, see confirmed plans and keep the conversation attached to the right playdate. HappyHuddle brings that parent-led journey together while keeping public activity discovery separate from family records.

What it does

HappyHuddle helps parents discover nearby children with shared interests, inspect overlapping availability and send a playdate request. Matching ranks shared interests first and distance second; where there are no shared interests, the verified fallback ranks by distance. Discovery shows pseudonyms, age bands and coarse distance bands rather than contact details or exact geography.

The recipient receives an in-app notification and can accept or decline. Accepted playdates appear in both parents’ calendars and enable a two-way parent conversation scoped to that request. Proposed and declined requests do not enable chat. The synthetic journey also checks repeated actions, refresh, Back and Close navigation, and denial of another family’s access to requests, messages and child-specific actions.

The core demonstration uses fictional parents and children in the actual website and mobile-web interfaces, backed by real Spring authentication, journey, persistence and cache services with an isolated in-memory H2 database. External providers are disabled and the verified runs recorded zero outbound provider calls. These are synthetic browser demonstrations, not production family accounts or installed Android/iOS tests.

A separate Alexa+ track contribution provides six read-only MCP tools for fictional public clubs and sports equipment. Adults explicitly choose activities and a broad area; the public tools do not accept family profiles, child identifiers or family calendars. It implements MCP 2025-11-25 over Streamable HTTP using the official SDK. It makes no booking or purchase and has no live Alexa connection, account linking or certification.

How we built it

HappyHuddle existed before 31 August 2026 as part of a different project and repository. It was later moved into the current HappyHuddle repositories; their creation dates do not mark the project’s original start. We are not claiming that the whole application was created from scratch during the event.

During the submission period, we added the isolated public-discovery MCP contribution and corrected request-ID correlation, protocol-versus-tool errors and notification non-execution. Later verified core updates include loading accepted calendars on screen focus, restoring journey Back navigation, keeping mobile calendar/account routes reachable and adding a reproducible synthetic browser qualification harness. The existing application and these later updates are identified separately.

The core interfaces use TypeScript, React and React Native/Expo with a Java/Spring backend. The browser qualification uses Chromium, including a 390 × 844 mobile-web viewport, and isolated H2 fixtures. The independent public module uses Node.js 24+, MCP TypeScript SDK 1.32.1 and Zod 3.25.76 with locked dependencies. Its deterministic catalogue and loopback-only transport require no private family database or paid provider.

Challenges we ran into

A request state must agree across both parents’ screens, calendars and chat permissions, including after repeated actions and navigation. We corrected calendar focus/loading and route behavior, then checked the real interfaces against the services rather than treating exports or isolated runner checks as browser acceptance.

The public MCP boundary needed separate protocol checks. An offline preview or a spoken-style text summary does not prove a live MCP client or Alexa connection. Keeping the public catalogue independent avoids sending family information through that experimental interface.

Accomplishments that we are proud of

On 22 October 2026, the actual Chromium website and mobile-web core journeys passed discovery/ranking and distance fallback, request creation, recipient in-app notification, acceptance, both calendars, two-way request chat, decline/no-chat, repeat/navigation behavior, third-family denial and contact/exact-location exclusion checks. The runs used real services with synthetic H2 data and zero outbound provider calls.

Separate scoped checks recorded 13 backend, 222 frontend and 262 mobile passes, with type and lint checks passing. These counts describe those checks, not a full native/MySQL campaign or production acceptance.

The core browser evidence is pinned to frontend 449cf8b5df292b6df034781c31d8d3cabb820e4b, mobile 7d1f15455f999b8500bfc68d6b96ab344b935104 and backend 038031324434035606ef02add6b0ea064b6f8b9c. Recording provenance is retained at backend evidence checkpoint 89bba8541adc7cffbc5f6a4a6f3ab0e625fde99d.

Separately, the public MCP module at source checkpoint 46a1593ba8c88d80f2d08e05df777c4294d78cb9 passed 20 focused protocol test groups and 11 actual HTTP demonstration steps. Its initialize response negotiated 2025-11-25, followed by tool discovery and calls. This is bounded local protocol evidence, not live-Alexa or full-application certification.

What we learned

The useful test is the parent’s complete path, not just a successful individual endpoint. Both participants’ calendars, the request’s state and chat access need to remain consistent. Reproducible synthetic fixtures let us check those boundaries without using real children’s data or contacting external providers.

What is next for HappyHuddle

Installed Android/iOS acceptance, real registration and email-verification journeys, and the full native/MySQL campaign remain unrun. The isolated H2 browser result does not establish those outcomes. Production use still requires operational, privacy, security and legal review.

The public catalogue remains fictional. Live provider data and any future Alexa integration would require appropriate access, authentication, data rights and separate testing. No production readiness or Alexa certification is implied by this entry.

Demo disclosure

Narration is AI-generated using an authorized voice. The demonstration uses synthetic families and public-catalogue listings. The core application and the separate public-discovery MCP prototype are shown as distinct parts of the project.