Harold is where I work directly with the physical limits of a product: a real display, real sensors, embedded timing, power constraints, and behavior that has to make sense on the device—not just in a browser mockup.
A live face running on the physical display during bench work.Local MaxBot bench-proof photograph.
My role
Product and embedded engineering
Status
Bench prototype
Contribution
Hardware bring-up, local interaction design, firmware states, and evidence-based release work.
ESP32-S3
C++
PlatformIO
Touch UI
IMU
01
Here’s the problem
The work has to make sense before the interface can.
A hardware prototype can look complete long before the physical system is actually proven. The work needs a clean line between browser concepts, compiled firmware, flashed hardware, and behavior observed on the bench.
02
What made this difficult
The environment is part of the product.
The interface has to remain readable on a 240 × 280 display.
Firmware, build artifact, flashed target, and observed behavior are separate evidence levels.
Child and family surfaces stay local-first without implying accounts, surveillance, or cloud control.
03
Decisions that shaped it
I made the hard boundaries visible.
Design for the real screen
The face and games are shaped around the display, touch target, and hardware state rather than a desktop composition.
Keep evidence traceable
Releases record the source commit, build artifact, flashed target, and observed behavior separately.
Keep the product local
The current direction avoids accounts, microphones, cameras, and invented cloud capabilities.
The embedded board behind the current display and interaction work.Local MaxBot bench-proof photograph.04
What I built
Enough of the system to test the real seam.
ESP32-S3 firmware with display, touch, IMU, and local interaction states.
Procedural face system and direct game access designed for a small physical screen.
Browser-based interaction labs kept separate from physical device acceptance.
What is true now
A working bench platform and a disciplined path for developing the personality, interface, and firmware without overstating what the hardware has proven.
Limits I’m keeping honest
Browser simulations do not validate the physical LCD, touch, IMU, battery, RF, or timing.
The portfolio does not imply remote device control or collected child data.
Next
Continue closing the gap between versioned firmware behavior and what is observed on the physical device.
