Your prototype runs when you connect your laptop and press Run. Now you want another team to put it into a smaller housing, prepare it for user trials or work out what a small batch would involve. The most useful handoff starts with the behavior and setup that already exist.
We use one of our own bench builds as the example: a shake-triggered game on a Raspberry Pi Pico-based controller board, with an MPU6050 motion module, a four-digit TM1637 display and a vibration module, programmed with blocks in BIPES, a browser-based editor for MicroPython. It has a visible assembly, a saved block workspace, the generated code and a demonstration video. Together those say much more than "it reacts when shaken."
Hand over the rule as well as the file
In this version, one gyro reading above 30 on any axis starts a sequence. The comparison is on positive values only, so a strong movement in the negative direction may not trigger it. The program picks a number, animates the display, shows the result and pulses the motor. It does not wait for the object to stop moving, and it does not read the sensor while the sequence runs. Those details belong in the handoff because they shape what a user will experience.
Describe what you want to keep and what you want to change. "Keep the visible result, but accept movement in either direction" is a request an engineer can implement and check. "Make it more responsive" leaves the receiving team guessing which part feels wrong.
Keep the block project file, the generated code and the required libraries together. Our code imports MPU6050 and TM1637 driver modules. Record their actual files and versions before transferring the build; a fresh MicroPython installation will not contain every project dependency.
BIPES is an open-source project that supports block and text workflows, and our build used a customized editor. Include that editor address and the selected board profile. Reopening the blocks is a separate check from running the generated program on the intended hardware.
Preserve the physical arrangement
The board artwork records both socket names and signal positions. The game uses GPIO4 and GPIO5 for I2C, GPIO7 and GPIO8 for the display and GPIO9 for the motor control. Send that mapping with a photograph of the specific board revision, not as bare pin numbers.
Module details matter too. On the vibration module, one signal position is marked NC (not connected) and the other DOUT. The receiving engineer also needs the module's power requirements and driver arrangement before replacing it with a different motor or changing the supply. The plug-in cable arrangement on the bench does not answer those questions.
The transparent mounting platform is useful because the relative positions of the parts are visible. If the later enclosure moves the motion sensor or changes how the object is held, the sensor sees different motion, so repeat the movement trial in that arrangement. A smaller shape is part of the interaction, not just a cover over unchanged electronics.
Separate running now from starting on its own
A program sent from the editor through the serial console can run perfectly without proving it will start after power is disconnected. MicroPython's reset and boot documentation explains which files run at startup. The exact board and firmware still need a power-cycle check with the intended files installed on the board.
Our demonstration video is a reference for the visible build and the interaction, recorded with the editor session running. A new trial should record what happens after reconnecting power with the laptop unplugged. Record failures as well as the expected outcome, so the next person can recognize the difference.
What the handoff package should contain
- The written behavior rule, including what happens on a repeated shake or a shake during feedback.
- The block file, generated code, driver files and their versions.
- The editor address, board profile, firmware file and pin map.
- A photo of the board revision and the module arrangement.
- A short video of the current behavior, and the result of a power-cycle test without the laptop.
- The changes you want, written so they can be checked.
Once those checks are repeatable, the conversation can move to a smaller enclosure, cable retention, access to controls and assembly steps. Preparing a small batch adds further work: a repeatable functional test per unit, and settled component and assembly choices. A demo build carries no yield, cost or delivery record, so those have to be established rather than assumed.