Byotoa

• 

  Dashboard

Inspiration

Byotoa—short for “A Better Yoto App”—started with a simple family problem: a Yoto Player is wonderful for independent listening, but it cannot create the kind of dependable bedtime flow we wanted. We imagined choosing several stories, letting them play in order, and then transitioning automatically to a sleep sound for the rest of the night.

That idea grew into a broader vision: a calm, family-first control surface that gives adults useful structure without taking away the physical cards and simple controls that make Yoto special.

What it does

Byotoa securely connects to a family’s Yoto account and turns a shared player into a more flexible listening system. Adults can:

• See connected players and live playback information.
• Search and browse their Family Library.
• Build persistent, player-specific queues from individual stories and tracks.
• Start a queue that advances automatically, even after the browser closes.
• Configure and manually start Free Play Night Mode with a story-time allowance.
• Keep the nighttime ending in place until a configured morning time.

The current version is a working vertical slice. More advanced household policies and child profiles are represented in the product direction but are not yet enforced.

How we built it

We built Byotoa with SvelteKit, Svelte 5, and TypeScript, deployed on Cloudflare Workers. Cloudflare D1 and Drizzle store accounts, Yoto connections, queues, and Night Mode routines, while Better Auth provides application authentication.

Yoto is connected through a confidential OAuth flow. Access and refresh tokens are encrypted with AES-GCM before being stored, and rotated refresh tokens are persisted safely.

Live playback and control use Yoto’s MQTT-over-WebSocket interface. Each player gets its own Cloudflare Durable Object, which acts as an always-on coordinator: it owns the active queue state, listens for playback events, serializes commands, schedules time boundaries, and prevents the same transition from being processed twice.

Challenges we ran into

The biggest challenge was that real hardware behavior is much messier than a simple “track ended” event. A Yoto Player can emit delayed, duplicated, or out-of-order updates, and the end of a card may produce several different cleanup events. We had to correlate events with the active item and make every transition idempotent so a duplicate event could never skip a story.

Targeted playback also required experimentation. Sending only a new chapter identifier could briefly interrupt playback and then resume the previous position. We learned that reliable targeting required the chapter, its intended track, and an explicit starting position.

Long-running coordination was another challenge. A queue must continue after the browser closes and survive serverless restarts, token refreshes, dropped MQTT connections, and Worker deployments. Durable Objects gave us the right foundation, but local development revealed platform-specific differences between Vite’s proxy and the complete Wrangler runtime.

Accomplishments that we're proud of

We are especially proud that Byotoa works with a real Yoto Player rather than stopping at a UI prototype. A two-item queue has successfully advanced at the natural boundary, kept the interface synchronized, and stopped after the final item instead of continuing into unrelated content.

We also built a persistent Night Mode state machine that can manage allowances, grace periods, sleep transitions, quiet endings, morning cutoffs, and restoration after interruptions.

The security and privacy foundation is another major accomplishment: encrypted tokens, server-side authorization, least-privilege data access, and diagnostics that avoid storing raw playback payloads or content identifiers.

What we learned

We learned that device automation is mostly about handling uncertainty safely. A trustworthy coordinator cannot assume that every status change means completion or that every event arrives exactly once. Sometimes the correct behavior is to pause and ask for attention rather than guess and unexpectedly replace family playback.

We also learned that serverless infrastructure can support persistent physical-device coordination when responsibilities are divided carefully: D1 stores durable application data, while a per-player Durable Object owns the live state machine.

Most importantly, family technology needs to feel understandable. Clear adult confirmation, visible state, respectful handling of physical-card interactions, and graceful failure behavior matter just as much as the underlying automation.

What’s next for Byotoa

Next, we plan to validate Night Mode end to end on real hardware and enable the Bedtime Queue path so a saved sequence of stories can transition directly into a sleep sound.

We also want to harden reconnection, retry, recovery, and external-playback handling before trusting the system for unattended nightly use. After that, the roadmap includes household invitations and roles, child profiles, schedules, listening allowances, sibling turn-taking, content rules, spoken announcements, and shared-player policies.

The long-term goal is for Byotoa to become a dependable family listening companion: powerful enough for adults, understandable to children, and quiet enough to fade into the bedtime routine.

Built With

• better-auth
• cloudflare
• svelte
• yoto