Bontoys by BenranFor product & sourcing
You get a staged pilot with an explicit go/no-go gate at every step — and a written scope before any spend.
Skip to the pilot path
For partners
Add voice to your line — without betting the line on it.
A staged path from one product photo to a working pilot, with an explicit go/no-go gate at every step.
Start where you sit
One pilot, three desks.
Each role gets a straight answer first, and a jump to the section written for it.
For engineering
Envelope, power, acoustics, and mounting are published below as design targets — confirmed at the structure review, before any tooling.
Skip to the module specsFor legal & compliance
No certification claims today. The data-flow checklist and the public R&D record are open for your review right now.
Skip to data & safety Q&ACategory fit
Which shelf is your toy on?
The module is designed for the toys already on your line. Pick the closest shelf — the application starts there.
Plush & soft toys
Soft bodies hide the bracket best — openings and mounting are planned at the structure review.
Discuss this shelf →Role-play & scene sets
Scene sets are our home turf — the scenario method was built on shop, kitchen, and trip play.
Discuss this shelf →Electronic learning
Existing electronics give the module power and openings to build on; fit is confirmed per model.
Discuss this shelf →Vehicles & others
Wheels, figures, and everything between — send a photo and we review the envelope first.
Discuss this shelf →For the engineering desk
The module, on one page.
The numbers we plan around today — every row opens the requirements checklist behind it.
- Module envelopeTarget ~65 × 45 × 20 mm (design value, confirmed per integration)
- Power300–500 mAh Li-po, USB-C charging (design target)
- Acoustics1× full-range driver + noise-tolerant mic array (design target)
- MountingSnap-fit bracket, no screws into the toy shell (design target)
- ConnectivityOffline-first; optional Wi-Fi hybrid for content updates
- Audio data flowSee the connected-toy data-flow checklist
All values are design targets confirmed at the structure review, before any tooling spend.
The pilot program
Three stages, three written deliverables.
Each stage ends with a go/no-go gate — we would rather say “no” early than sell your toy a module it doesn’t need.
Assessment
We study how children actually play with the toy today, and where an answer would earn its place.
Deliverable: play review memo
Prototype integration
Module, scripts, and your structure, tested together in real play conditions.
Deliverable: integrated prototype + test notes
Pilot decision
Both sides review the evidence and decide go/no-go with everything on the table.
Deliverable: pilot readiness decision
First play-pattern review back within 5 business days · integration measured in weeks, not quarters
We run 3 pilot slots per quarter to keep every integration hands-on.
Commercials
Why we don't publish a price list
Every toy's structure, volume, and content scope differ. After the structure review you get a written scope — module, dialogue content, integration work — and a quote against it. No scoping or review fee; integration costs are quoted only after the structure review.
Compliance
Certification and responsibility, said plainly.
No certification claims today; formal child-privacy review (e.g. kidSAFE-type programs) is planned to begin alongside the first brand pilot.
- Module firmware & updates
- Bontoys
- Whole-toy safety certification
- The brand
- Child data posture
- Shared — per the data-flow checklist
- US
- COPPA posture per the data-flow checklist
- UK
- PSTI-style support-window statement planned
- EU
- RED / EN 18031 applicability assessed per SKU
Module-level work does not replace whole-toy certification.
Data & safety
The six questions your team will ask anyway.
When does audio leave the device?
By design, it does not in the default configuration: the module is offline-first. The optional Wi-Fi hybrid is reserved for content updates, and any connected path is mapped with your team in the data-flow checklist before a pilot starts — not after.
What is stored, and for how long?
The module is designed around play sessions, not profiles: no child account, no voice archive. Where a connected option adds diagnostic logging, scope and retention are fixed per integration and written into the pilot agreement.
What can parents see?
Parents should be able to understand the toy without a manual: what it listens for, when it answers, and how to turn it off. The exact parent-facing controls are defined per integration and reviewed at the prototype gate.
Who owns updates?
Bontoys owns module firmware and dialogue-content updates for the life of the pilot agreement. Whole-toy software, recalls, and market-specific compliance stay with the brand.
What happens at end of life?
End of life is agreed before the pilot begins, not after: update stop dates, service behavior, and data deletion are all covered in the pilot agreement.
How can our legal team validate your data practices before formal certification?
Start with two public documents: the connected-toy data-flow checklist maps what moves where, and the public R&D record shows what we publish and why. Both are open today, and we answer written questions against them.
Support
Support boundaries, up front.
Inquiry response within 2 business days · firmware/content updates owned by Bontoys · EOL policy covered in the pilot agreement.
Ready when you are
Start with the toy you already sell.
Send one product photo and the play pattern you want to protect. The first gate — and the honest “no” if voice adds nothing — is on us.