Is a batch file launching my PowerShell GUI a reasonable setup?

A batch file that starts the script is a perfectly reasonable way to begin. You probably do not need to turn this into a standalone executable. Keep the script and launcher in one shared folder, and make the output path configurable instead of tied to your own machine.

For example, let the script accept the PO number and an output path as parameters. The GUI can supply those values, and the launcher can point to the current script. When you need to update it, replace the script in that location, assuming your coworker has permission to access it.

I’d add a Save As option, or at least let the user choose an output folder. Saving beside the launcher can be confusing, and users may not have write access to that shared location.

Also make the GUI show where the CSV was saved and give a clear error if the API call or file write fails. Those small details will make it much easier to support when something goes wrong.

Before packaging anything, separate the actual work from the interface. Have one function take a PO number and output path, handle the API request, and create the CSV. The GUI should collect the input and display the result. That makes it easier to test the processing separately and change the interface later.

Think through what happens with a bad PO, a network or API failure, and an existing output file. A short status message or log can help with troubleshooting. If only one coworker needs this and the script runs in your environment, the shared script plus launcher may be simpler to maintain than an executable.

One thing to sort out early is support. If the script stops working, who will check the API response, permissions, or an incorrect PO? Add basic validation and useful error messages, then give the coworker a simple way to report the input and error details. If the process is too fragile to support, a spreadsheet-based handoff may be less work for both of you.