The next big move for storytelling devices
By Filippo Yacob
Most of the kids’ audio category has been built around storytelling. That makes sense. Stories are safe, contained, repeatable and easy to package into physical objects. Yoto has cards, Tonies has characters, and FABA has statuettes. These products have done something genuinely important: they have made audio physical again.They have taken listening away from phones and tablets and turned it into something children can touch, carry, choose and control.
But there is a bigger opportunity sitting right next to the story catalogue: MUSIC.
Not music as another catalogue to license, own or sell. Music as a safe, parent-controlled listening experience built on top of the streaming services families already use.
Most parents already pay for Spotify, Apple Music or YouTube Music. They already make playlists for their kids. They already know the songs their children love. They already have bedtime playlists, dance playlists, Disney playlists, calm-down playlists, car playlists, film soundtracks, nursery rhymes, podcasts and audiobooks sitting inside services they pay for every month.
So the problem is not access to music.
THE PROBLEM IS HOW TO LET A CHILD INTERACT WITH THAT MUSIC WITHOUT HANDING THEM A PHONE.
That is where companies like Yoto, FABA, Tonies and others have a much bigger opportunity than simply adding more stories. They can become the missing control layer between a parent’s streaming account and a child’s need for independence.
They do not need to become another streaming service.
They need to become the safest, simplest and most child-friendly way for families to use the streaming services they already have.
THE BIG IDEA
The big idea is simple: PARENTS CHOOSE THE MUSIC WORLD, AND CHILDREN GET FREEDOM INSIDE IT.
A parent opens the Yoto, FABA or Tonies app. They connect their Spotify account. They choose a playlist, album, podcast, audiobook, artist collection or family mix. Then they assign that approved audio space to a card, character, statuette, button, routine or speaker mode.
From the child’s perspective, nothing feels complicated. They place the character on the speaker, insert the card, press the music button, or select the approved mode. The music starts. They can play, pause, skip, go back, replay a favourite song, maybe shuffle if the parent allows it, and adjust the volume.
But they cannot leave the boundary.
They cannot search all of Spotify, browse adult podcasts, fall into recommendations, open video, access comments, pick up the parent’s phone, or turn a music moment into a screen moment. This is the old MP3 player idea, rebuilt for the streaming age.
OLD INTERACTIONS, NEW TRICKS - THE OLD MP3 PLAYER MODEL
The old MP3 player worked because it gave children autonomy inside a container. Once the music was on the device, the child could explore freely, but they could not fall out of the approved world. That limitation was not a bug. It was the safety model.
The streaming-era version should work the same way. The parent defines the boundary. The child controls the experience. This is not “Spotify for kids” in the normal app sense. It is a child-safe control layer.
The speaker company does not own the songs, does not have to build the catalogue, and does not have to compete with Spotify. It simply turns an existing family subscription into something younger children can use safely, physically and independently.
For Yoto, this might be a Spotify Card. For FABA, this might be a Spotify Statuette. For Tonies, this might be a Family Music Tonie. The object does not need to contain the music. It simply acts as the key to a parent-approved streaming container.
That is the service: NOT OPEN STREAMING, BUT BOUNDED STREAMING.
THE TECHNICAL INTEGRATION HYPOTHESIS
The technical architecture is not as simple as “just connect the Spotify API.” That distinction matters, because Spotify’s normal public developer tools are not a shortcut for building a commercial child-facing streaming product. Spotify’s Developer Policy places limits on products targeted to children through the standard Spotify Platform, and Spotify’s commercial hardware tools are available only for approved partners. (developer.spotify.com)
So the correct route for a company like Yoto, FABA or Tonies is not a normal third-party API build. It is a formal Spotify hardware partnership.
Spotify already has a commercial hardware path for approved partners, including Spotify Connect-style device experiences and the Embedded SDK. In that model, the hardware can become an approved playback endpoint, but Spotify requires certification and a signed distribution agreement before launch. Its technical requirements also state that commercial products using the Embedded SDK must sign a licence and distribution agreement with Spotify. (developer.spotify.com)
That means the speaker company should not be copying tracks, downloading unprotected audio, storing music outside Spotify’s rules, or creating a parallel rights problem. The cleaner version is that Spotify remains the licensed music service, and the storytelling device becomes the approved playback and control surface.
THE PARENT APP AS A CONTROL LAYER, NOT A CATALOGUE
The parent app would handle the adult-side account linking and permission flow. A parent connects their Spotify account through an approved authentication route, selects a playlist, album, podcast or approved audio container, and assigns it to a card, statuette, character or speaker mode.
The child never gets open access to Spotify. They only interact with the physical object and the limited controls the parent has approved.
The speaker receives only the instructions it needs: what to play, what controls are allowed, and what boundaries must be enforced. A Yoto card might point to a playlist ID. A FABA statuette might point to a bedtime playlist. A Tonie character might point to a rotating family mix. The device then acts as a certified playback endpoint rather than a separate music service.
Offline mode should probably not be the first version. Downloads usually create more rights, DRM and platform-rule complexity. A safer first version would be streaming-first: the parent assigns the playlist, the device streams it through Spotify’s approved hardware integration, and the child controls playback within the approved boundary.
THE SAFETY CONTROLS
This is where the product becomes much more than a speaker integration.
A basic implementation would let parents assign playlists and block open search. A better implementation would let them shape the whole listening environment around the child, the household and the moment.
Parents could decide which playlists are allowed, which podcasts are blocked, whether explicit tracks are filtered, whether shuffle is allowed, whether repeat is allowed, whether the child can skip freely, and whether the device can continue playing once the approved playlist ends.
They could also create different listening modes. A bedtime mode might only allow calm music after 7pm. A morning mode might allow a getting-ready playlist. A car mode might allow family favourites. A weekend mode might allow podcasts, while weekday evenings might not. The point is not just to connect Spotify. The point is to give parents a simple way to create safe audio spaces.
The device could also support child profiles. One child might get access to Disney songs, bedtime stories and classical music. Another might get football podcasts, movie soundtracks and piano playlists. The parent should be able to assign different rules to different children and different devices, rather than treating the whole household as one listening account.
There is also a safety layer around behaviour. Parents may want volume limits, quiet hours, listening history, battery alerts, location-specific settings, or a way to remotely stop playback. They may want to know if a podcast episode contains mature themes, or if a playlist has songs that are marked explicit. They may want recommendations turned off entirely, or limited to parent-approved sources only.
That is the real value of the speaker company. Spotify provides access to music. The storytelling device provides the physical ritual. The parent app provides the boundary.
The best version would make all of this feel simple. Not a complicated dashboard. Not enterprise parental control software. Just a few clear promises: choose what is allowed, decide how much freedom your child has, and let them listen safely without your phone.
THE COMMERCIAL ASPECT
The commercial opportunity is powerful, but it should not be described as free. It would almost certainly cost something to build: engineering, firmware, parent-app changes, partner management, privacy review, legal review, certification, QA, customer support and ongoing maintenance.There may also be negotiated commercial terms with Spotify, because Spotify does not publish a simple self-serve per-device tariff for this kind of hardware integration, and commercial hardware approval is handled through its partner process. Spotify’s onboarding page says its commercial hardware tools are only for approved partners, that it accepts applications from companies rather than individuals, and that final approval is at Spotify’s discretion. (developer.spotify.com)
But that is not the same as licensing a global music catalogue.
That is the crucial point. The commercial unlock is not “zero cost.” The commercial unlock is “avoid the wrong cost.” A company like FABA or Yoto would not need to negotiate directly with labels and publishers, build a catalogue, maintain a music rights operation, or ask parents to buy the same songs again inside a smaller ecosystem.
Spotify already has the catalogue. Parents already pay for access. The speaker company can focus on the thing it is actually good at: safe, tactile, child-friendly control.
THE COST MODEL FOR A COMPANY LIKE FABA
For planning purposes, I would think about the economics in three simple scenarios.
In the most attractive scenario, Spotify sees the integration as a way to increase Premium and Family usage, so the hardware partner does not pay a meaningful recurring per-user fee. In that case, the marginal cost per active connected device could be very low, maybe around €0.00–€0.10 per month, mostly covering the speaker company’s own backend and device-management overhead.
In a more realistic partner-fee scenario, Spotify may require some form of commercial arrangement, certification economics, support fee, fixed annual partner fee, or negotiated usage fee. For internal modelling, I would assume something like €0.10–€0.50 per active Spotify-connected device per month.
In a heavier commercial scenario, especially if the speaker company packages “Spotify Mode” as part of a paid subscription, the economics could become more structured. In that case, I would model something closer to €0.50–€1.50 per active connected device per month, or a revenue share on any paid feature that uses the integration.
None of these are known Spotify prices. They are planning assumptions. The actual terms would be negotiated.
THE REAL COST TO INTEGRATE
The bigger cost would probably be upfront.
A credible first version could require €150k–€500k of product, firmware, app, backend, QA, legal and certification work, depending on how ready the hardware is and how deeply the experience is integrated. Ongoing maintenance might add €25k–€150k per year for SDK updates, support, compliance, QA and partner management, before any Spotify-specific commercial fees.
Even with those costs, the proposition remains commercially attractive because it is fundamentally different from building or licensing a catalogue. The company is not paying to own music. It is paying to become a trusted control layer for music families already pay to access.
The message to customers is simple: YOU ALREADY PAY FOR SPOTIFY, NOW YOUR CHILD CAN USE A PARENT-APPROVED SLICE OF IT SAFELY, PHYSICALLY AND WITHOUT A PHONE.
THE DIY ROUTE FOR PARENTS
There is also a more DIY route here, and it may be the fastest way for this idea to become real.
The ideal version would be for an open-source hardware company to build this kind of speaker from the ground up, and for someone to provide the whole stack openly: the hardware reference design, the firmware, the parent app, the playlist assignment layer, the safety rules, and the physical interaction model.
That does not mean asking every parent to become a hardware engineer. Most parents are not going to 3D print a speaker, wire together a Raspberry Pi, flash firmware, troubleshoot batteries, and trust a homemade object in a child’s bedroom. The problem with the pure maker version is not that it cannot work. It is that it asks too much of normal families, and often lacks the durability, reliability and confidence of an industrially produced product.
The better DIY route would be “DIY without the pain.” Parents should be able to assemble, customise, repair or configure the device without needing to understand electronics.
HOW SCHEMATIK COULD MAKE THIS POSSIBLE
A company like Schematik points to one possible route. Schematik describes itself as an AI hardware IDE for Arduino, ESP32 and Raspberry Pi Pico-style projects, where a user can describe what they want to build and receive code, wiring diagrams and step-by-step instructions. (schematik.io)
That kind of tooling could make a child-safe MP3-player project much more accessible to non-technical parents, schools, clubs and maker communities. Instead of starting with a blank circuit board, a parent could begin with a guided build: choose a speaker module, choose buttons, choose a screen or no screen, choose Wi-Fi or offline-only, choose battery type, then generate the wiring, firmware and setup instructions.
The magic here is not that every family will build their own device. Most will not. The magic is that the open project becomes easier to understand, adapt and trust. It lowers the barrier between a product and a platform.
HOW BAMBU LAB AND TOYBOX COULD HELP
Bambu Lab is another interesting piece of the puzzle because its ecosystem is already moving beyond “download a 3D file and figure it out yourself.” MakerWorld is Bambu Lab’s platform for sharing printable models, and Bambu has also explored reusable programmable electronics through CyberBrick-style kits for 3D-printable toys. (makerworld.com)
Toybox, or another family-friendly 3D printer company, could do something similar from the consumer side. Instead of asking parents to navigate a technical maker ecosystem, the device could be packaged as a printable family project: choose the music player body, print the shell, snap in the certified electronics module, and pair it with the parent app.
That matters because the physical shell of a child-safe music player could become part of a broader printable ecosystem. A parent might buy the electronics kit, then print the enclosure in a shape, colour or character style that suits their child. One family prints a bedtime radio. Another prints a dinosaur speaker. Another prints a little music cube. Another prints a wearable clip-on player.
This is where the “fabled” experience gets interesting. The device does not have to be a generic black box. It can become a physical object with story, ritual and character, while still being powered by a safe audio stack underneath.
TINKERCAD, DIY.ORG AND MAKERWORLD AS DISTRIBUTION LAYERS
The distribution layer for this kind of project could be just as important as the hardware.
Tinkercad could make it easy for children, parents and teachers to customise the physical body of the device. A child could remix the shape, add their name, change the button layout, design a stand, or create a character shell. The electronics remain standard, but the personality of the object becomes theirs.
DIY.org could serve a similar role, but with a stronger learning and community layer. The project could become a guided build: design your music player, understand how buttons work, learn what makes a device safe, customise the enclosure, assemble the kit, and then use the parent portal to choose approved music. That turns the device into both a product and a learning experience.
MakerWorld could become the printable object marketplace around the idea. Families could browse approved shells, characters, stands, holders, accessories and protective cases. Some designs could be official. Others could be community-made. Some could be tied to routines: bedtime, dance time, road trips, quiet time, study music, and grandparents’ playlist.
This gives the project a distribution model that is not only retail. It becomes a platform for creativity, customisation and learning.
KIBU AS A MODEL
KIBU is a strong example of the kind of company that could do this well. Its headphones are positioned around children building, repairing and recycling them, with a modular design made from recycled materials. The product is designed to be assembled by children and repaired rather than thrown away. (kickstarter.com)
That ethos maps beautifully onto a child-safe MP3-player experience. KIBU could open-source parts of the design, sell the finished device or kit, and build the business not around owning a catalogue, but around the safety controls, the hardware, the repairable ecosystem and the parent experience.
Instead of selling songs, KIBU could sell the thing families actually need: a safe, sturdy, buildable, repairable way for kids to control music without a phone.
That feels much more aligned with the future of children’s audio than yet another locked content library.
OPEN SOURCE DOES NOT CANNIBALISE THE PRODUCT
The most important thing to understand about open sourcing the hardware is that it does not necessarily cannibalise the finished build. In fact, it can do the opposite.
We learned this with Cubetto. Cubetto always had an open-source version. The original designs were available from day one, which meant the idea existed as both a product and a platform. In theory, anyone could make their own. In practice, almost nobody did. The number of customers who printed or built their own Cubetto was less than 0.1%.
That is the point.
Open source did not destroy the commercial product. It strengthened the story around it. It gave educators, makers, researchers and parents confidence that the product was not a sealed mystery box. It made the idea more generous, more inspectable and more culturally interesting, while most customers still bought the finished version because it was easier, safer, better made and ready to use.
The same would likely be true here. A family could technically print the enclosure, source the electronics and build the device. But most families would rather buy the finished product or a polished kit.
The open-source layer becomes a platform, not a threat.
THE ASTROSAFE LAYER
This is also where a company like AstroSafe could play a useful role.
The opportunity is not only to build one speaker, one card, or one Spotify integration. The bigger infrastructure opportunity is to provide the parent portal and safety layer that can sit across many child-friendly audio devices, streaming services and hardware categories.
Imagine a parent app that lets a family connect the streaming service they already use: Spotify, Apple Music, YouTube Music, Amazon Music, local MP3s, audiobooks, podcasts or approved RSS feeds. The parent chooses what is allowed, creates or imports playlists, applies safety settings, and then sends that approved audio world to a device.
That device could be a Yoto-style speaker, a FABA-style statuette player, a rugged streaming MP3 player, a child-friendly portable speaker, a tablet in audio-only mode, or an open-source hardware product. AstroSafe’s role would not be to own the music. It would be to provide the trusted control plane.
WHAT ASTROSAFE WOULD MANAGE
The parent portal could manage which child gets access to which playlists, whether explicit tracks are blocked, whether podcasts are allowed, whether search is disabled, whether recommendations are off, what time of day the device can be used, whether the child can skip freely, whether volume is capped, and whether listening history is visible to the parent.
The safety layer could also normalise different streaming services into one parent experience. Spotify may have one integration model. Apple Music may have another. YouTube Music may have different constraints. Local MP3s are different again. A family should not need to understand all of that. They should simply be able to say: this music is allowed for this child on this device.
That is the real infrastructure opportunity.
AstroSafe could provide the parent account system, device pairing, child profiles, playlist permissions, safety policies, audit logs, age settings, explicit-content rules, safe podcast controls, and a simple API for hardware partners. A device maker could then focus on the industrial design, speaker quality, buttons, battery life and physical ritual, while AstroSafe provides the safe audio operating layer underneath.
In other words, AstroSafe could help turn almost any smart speaker, MP3 player or music-like portable device into a safe MP3 player for kids.
Not by replacing Spotify. Not by licensing music. Not by building another catalogue. But by creating a parent-controlled wrapper around the audio sources families already use.
THE BENEFITS OF THIS BIG IDEA
The customer wins first because they can use the subscriptions they already pay for without buying the same music again or handing over a phone every time a child wants music. They get a simple way to say: this playlist is okay, and you can explore freely inside it.
Children win because they get independence without exposure. They can develop taste, replay songs, skip tracks, make choices and feel ownership over their listening experience, but without being thrown into an adult app, open search, recommendations, videos or comments.
Spotify wins because it expands into a family use case it does not fully solve today. Parents already use Spotify with children, but the phone is usually the interface. A partnership with a trusted kids’ speaker company gives Spotify a screen-light, physical, child-friendly presence in the home. It increases usage without requiring Spotify to build a Yoto or FABA-style hardware experience itself.
The speaker company wins because the device becomes dramatically more useful. It stops being only a story player or proprietary content box and becomes the child’s safe audio companion. That means more daily engagement, more relevance, stronger retention, more reasons to gift the device, and a broader role in the family’s audio life.
AstroSafe or a similar infrastructure company wins because it becomes the missing control plane between streaming services, hardware partners and families. Instead of every device maker building its own parent portal, safety rules, account system and playlist permission architecture from scratch, they can plug into a shared layer purpose-built for child-safe media access.
POSITIONING AND PACKAGING THE IDEA
The way this is packaged matters. This should not be positioned as “open Spotify on a kids’ speaker,” because that sounds too broad, too risky and too close to giving children unrestricted streaming. It should be positioned as safe, parent-approved music control.
For Yoto, the product could be launched as SPOTIFY CARDS FOR YOTO OR YOTO MUSIC CARDS WITH SPOTIFY. The message would be simple: assign any parent-approved Spotify playlist to a Yoto card and let your child listen independently, without a screen. The card becomes a physical playlist. Not a new catalogue. Not another subscription. A safer way to use the music your family already loves.
For FABA, the idea could be packaged as FABA MUSIC MODE OR FABA X SPOTIFY FAMILY LISTENING. A special Spotify statuette could unlock the experience. Parents assign a playlist in the MyFaba app, place the character on the speaker, and the child gets safe access to that approved music world.
For KIBU, the positioning could be even more interesting: THE OPEN-SOURCE MP3 PLAYER FOR THE STREAMING AGE. Build it, repair it, customise it, understand it, and let your child control music safely. The catalogue is not the product. The safe, physical, repairable listening experience is the product.
For AstroSafe, the positioning could be broader still: TURN ANY CHILD-FRIENDLY AUDIO DEVICE INTO A SAFE MP3 PLAYER FOR KIDS. The promise would be that parents can connect the services they already use, choose the music their child is allowed to hear, and send it safely to a device the child can control.
THE LAUNCH MESSAGE
A launch campaign could focus on the parent pain point: your child loves music, but you do not want to hand them your phone. Then the product promise becomes: connect your music service, choose a playlist, and let them listen safely.
The commercial messaging should be equally clear. No duplicate music subscription. No open search. No phone. No need for the speaker company to build or license a giant music catalogue. Just the music your family already pays for, inside a device your child can control.
For Spotify, the partnership could be positioned around family listening. Spotify becomes more useful in homes with young children, without having to become a hardware company or redesign the entire app for preschoolers. For the speaker company, this becomes the next chapter after storytelling.
Not “WE NOW DO STREAMING.”
But: WE NOW LET CHILDREN SAFELY CONTROL THE MUSIC THEIR PARENTS ALREADY LOVE.
That is a much stronger and more defensible position. The category started by making stories physical. The next move is making music safe, physical and child-controlled.
Not another streaming service. Not another catalogue war. A control layer. A bridge. A safer, streaming-era MP3 player for families.