In software, a mistake can become another deployment. In hardware, it may already be inside a board, an enclosure or a shipment.
My background made the first AI Teddy software prototype feel tractable. I understood cloud services, machine learning, APIs and iterative delivery. The physical product introduced a different kind of system: one where observation is harder, feedback loops are longer and changes may carry material cost.
Software experience remains useful. It teaches decomposition, interfaces, testing and version control. It can also hide assumptions about reversibility and the cost of being wrong.
Learning to read a different system
A schematic is not simply code drawn as wires.
It captures power rails, signal interfaces, component values, physical connectors and assumptions that may not appear in prose. A datasheet can specify electrical behaviour without telling you whether the part is suitable inside a plush child-facing product. A bill of materials is simultaneously an architecture, a supply-chain plan and a cost model.
AI tools helped me navigate this language. I could use them to identify interfaces, compare documents and generate questions. But any confident interpretation still had to be checked against the source and reviewed by the people responsible for the hardware.
One useful habit carried over from software: mark uncertainty explicitly. “This pin is connected” is different from “the firmware suggests this pin is connected” and different again from “the production design has been verified”.
Working with a manufacturing partner
A manufacturing partner cannot implement an intention such as “the audio should be good”. They need a testable specification.
How loud must the speaker be in the final enclosure? At what distance and background noise? What camera field of view is acceptable? How far from the book should Ted sit? How much movement can the internal camera mount tolerate? Which design files, test fixtures and firmware packages belong to whom?
Ambiguity becomes expensive when it crosses language, time-zone and disciplinary boundaries. Meetings help, but written acceptance criteria and versioned source files matter more.
Prototype feedback became more useful when it separated blocking functional issues, strong preferences and accepted items. Visual and audio performance could be blockers; construction refinements could be quality preferences; other decisions could be explicitly accepted for one iteration.
That structure prevented every comment from becoming an uncontrolled redesign.
Component selection is product strategy
A camera choice affects OCR accuracy, field of view, image size, memory and transfer time. A microphone choice affects circuit design, acoustic placement and noise handling. A speaker affects volume, distortion, power and the shape of the enclosure.
Storage influences speed, longevity, update workflows and cost. A cloud-versus-edge decision changes processor requirements, connectivity, privacy and recurring service cost.
In software, teams sometimes treat infrastructure as separate from product strategy. In hardware, the connection is impossible to ignore. Every feature can touch the bill of materials.
Parts availability adds another dimension. A component selected for the prototype may become expensive, delayed or unavailable before production. A supplier may offer a “compatible” substitution that differs in driver support, power draw, acoustic behaviour or camera timing. We would treat substitutions like code changes: compare the specification, record the decision, rerun the affected tests and update the source of truth. A pin-compatible part is not necessarily a product-compatible part.
Prototype cycles feel different
A software loop can be edit, test and deploy in minutes. A hardware revision may require updated drawings, sourced parts, PCB fabrication, assembly, shipping and physical inspection.
That longer loop increases the value of early questions. It also increases the temptation to accept a prototype because the next iteration is slow.
We learned to test the complete enclosure rather than the electronics alone. Visual sensing and speaker performance changed inside the plush body, and construction choices could influence alignment.
The product is the assembled system, not the cleanest subsystem on the bench.
Manufacturing tolerance is a software concern
Software often assumes the sensor exists at a known position. Manufacturing produces a distribution of positions.
A few millimetres of camera shift may alter what part of the page is visible. Fabric and stuffing can vary. A button can rotate or feel different. An acoustic opening can become partially covered.
The response is a combination of mechanical control and software tolerance. The mount should be stable and the process repeatable. The vision system should still handle ordinary page placement. Neither discipline can outsource the complete problem to the other.
Battery, charging and heat
Battery capacity is not a single target. It sits beside charging time, cell protection, weight, cost, speaker volume, Wi-Fi use and the duty cycle of the camera.
The final enclosure makes thermal behaviour particularly important. Plush and stuffing are not heatsinks. A connector hidden behind a child-resistant access point may be safer but less convenient. A charging state that is obvious to an engineer may be confusing to a parent.
These decisions require qualified electrical and product-safety review. A team should resist the idea that a successful charge/discharge bench test is equivalent to consumer-product validation.
Certification begins before the final prototype
Toy safety, electrical and battery safety, radio requirements, materials, labelling, privacy and data protection all create design inputs.
We have identified these categories and incorporated them into the next phase. We have not completed certification and should not imply production readiness.
That wording may sound cautious. It is also accurate. A child-facing connected toy cannot stop at “the demo worked”.
Advice I would give a software-first founder
Write supplier-independent requirements. Describe what the component or system must do, not only the part currently selected.
Preserve the source files. PDFs are useful for review, but editable schematics, PCB layouts, mechanical drawings, firmware and test definitions determine whether you can maintain the product.
Clarify ownership early. Tooling, design files, firmware, manufacturing tests and revision history should not become ambiguous after money has been spent.
Test in the real enclosure as soon as possible. Acoustics, camera placement, temperature and handling do not exist in a diagram.
Budget for redesigns. A prototype is a learning instrument, not a small production run.
Treat servicing and safe updates as product features. The device will need fixes after the board is no longer on your desk.
Finally, know when to bring in specialists. AI can accelerate learning and software experience can improve the process, but neither substitutes for qualified hardware, safety, compliance and manufacturing expertise.
Building Tell Me Ted has made me a better software engineer because it has forced every abstraction to meet a physical consequence.
Next in the series: the decisions we would change if we started again and the few we would defend even more strongly.
Tell Me Ted is an independent, pre-launch project that I work on outside my role at HubSpot. The views expressed here are my own and do not represent HubSpot.