The light flashes when you click Run in Thonny. You disconnect the development computer, power the prototype from its intended supply, and nothing happens. For a first hardware demo, that can feel like a mysterious electrical failure. One simpler possibility is worth checking first: the program ran on the board, but was never saved there as its startup program.
Before handing a MicroPython prototype to a designer, educator or test user, separate three actions: running the code, storing the files on the device, and checking what happens from power-on. We walked through the first two on a Raspberry Pi Pico with Thonny. This note covers what each step shows, and how to set up the third check, which is the one that matters for a hand-over.
The distinction still catches people. In a March 2026 Thonny discussion, a builder could run a program in the editor but could not make it start on its own. They had copied main.py onto the drive that appears in bootloader mode. The maintainer explained that this drive accepts firmware, while ordinary MicroPython script files are handled through the running interpreter. No later success report was posted, so it is a clear example of the misunderstanding, not a finished deployment case.
First establish where the code is running
In Thonny you choose a backend: the part of the editor that talks to an interpreter. Selecting the board's MicroPython backend means the code is sent to the board's interpreter. A desktop Python selection would run ordinary Python on the computer instead. Choosing the board's backend does not mean the editor itself has moved onto the device.
In our session the shell identified MicroPython 1.23.0, dated 2024-06-02, on an RP2040-based Raspberry Pi Pico, connected as COM3 on that computer. Those details belong to that run. A Pico 2 or another computer can show a different firmware banner and port, so read the identification from the board you actually have connected.
Thonny's interpreter settings also show why an editor-connected test can differ from standalone use. Our configuration had three options enabled: interrupt the running program on connection, synchronize the real-time clock using local time, and restart the interpreter before running code. These are useful for development, but they change the state you are trying to observe.
A clock-dependent application may look correct after the computer has set its time. That says nothing about where the time comes from at an unplugged start. Reconnecting an editor that interrupts the program can also hide whether the startup program had already begun. Record these settings when you compare the two kinds of run.
What a successful Run proves
Our test program configured GP25 as an output, switched it on, printed LED ON, waited one second, switched it off, printed LED OFF and waited again, in a loop. GP25 is the LED on that board; check the LED mapping before using the same pin on another board.
After Run, the shell showed a soft reboot and then alternating ON and OFF lines. That is console output, not a measurement of the light. It is still a useful first result: the selected interpreter can execute the program and send output back.
It is not a standalone-start result. Thonny's MicroPython guide distinguishes running the editor's text from saving a script on the device. A successful Run alone does not tell you which files will still be there after power is removed.
Save a device copy, not just a computer copy
When you save in Thonny with a board connected, it asks where to save: this computer or the Raspberry Pi Pico. That is the crucial step. Keep the project's master files on the computer and deliberately save the deployment copy to the device. Before replacing an existing startup file, keep a copy of the version already on the board.
For a conventional MicroPython startup, the device's main.py is the application entry point. If you use an optional boot.py for setup, it has to finish so execution can reach the application. The MicroPython 1.27 boot-sequence reference describes these roles; use the documentation that matches the firmware on your unit. Naming a file main.py on the computer does not put it in the device's filesystem.
Then reopen the file from the device and check its contents. Check every imported driver and configuration file too, not only the entry point. A program that relies on a file still sitting on the development computer is an incomplete deployment.
The same goes for packages. Thonny's package manager works for the selected backend. Installing a dependency for the computer's Python is different from placing the module where the board can import it. For a reproducible demo, record the files actually present on the device and the firmware that runs them.
Keep firmware installation separate from script saving
On a standard Pico MicroPython setup, the USB drive exposed by BOOTSEL is the firmware-loading interface. It is not an ordinary folder for your application. Copying main.py there does not substitute for saving it to the running device.
Some boards and vendor firmware use other storage arrangements. A September 2026 Tufty 2350 support thread concerns file-copy behavior in that product's USB Disk Mode. The user eventually reported success after clearing the device and installing version 3.1.1. That is one firmware case, not a reason to erase an ordinary Pico whenever saving fails. Identify the board, firmware and storage mode before applying someone else's workaround.
Make the power-on check look like the user's first experience
Once the files are saved, stop using the Run button as the success criterion. Close the development session and do a deliberate power-off and power-on from the intended, correctly connected supply. Do not hold the bootloader button. Watch for a simple, visible startup result: a known LED pattern, a ready screen or another indicator that does not need a console. Our editor session did not include this unplugged test; it is the next step.
If the first indication never appears, reconnect for diagnosis, remembering that the editor may interrupt or restart the program. Check the device copy of main.py, its imports and any startup error. If the indication appears and the application fails later, look at the next dependency, such as network availability or a peripheral's initialization, instead of reinstalling the editor.
After the minimal test works, repeat it with the real application and have another person power it on using the short instructions you intend to hand over. Record the board and firmware, the deployed file versions, the power source and the observed result. Also keep a way for the developer to stop the application and make the next change, so an automatic startup program does not lock you out of the board.