Sooner or later a script grows a face. The tool-crib lookup, the setup-sheet generator, the inventory app that replaced the spreadsheet — someone besides you needs to use it, and that means a GUI. For Windows shop-floor software the shortlist is three names: PyQt/PySide (Python), WinForms (C#/.NET), and WPF (C#/.NET). I've shipped tools with all of them, and the honest answer to "which one?" has almost nothing to do with which framework is best.
The question that actually decides it
Not "which is most modern?" but: what does the rest of your automation already speak, and who maintains this after you? A shop whose scripts are all Python should not introduce a C# GUI for one app; a shop with .NET line-of-business software should not make IT learn Python packaging. Internal tools die from unmaintainability, not from being unfashionable.
PyQt / PySide — for the Python shop
- For: your GUI lives in the same language as your FOCAS collectors, Excel automation, and analysis scripts — one codebase, one skillset. Qt widgets are deep and genuinely cross-platform, so the same tool runs on the Raspberry Pi by the machine.
- Against: packaging is the tax. PyInstaller turns your app into a 150 MB folder, antivirus occasionally eyes it, and startup is slower than native. Livable, but real.
- Licensing, the trap: PyQt is GPL unless you buy a commercial license — a problem the moment your tool leaves the building. PySide6 is LGPL and is the default choice for anything commercial. Same Qt underneath, nearly identical API: when in doubt, PySide.
WinForms — boring, and proud of it
- For: the fastest path from nothing to a working CRUD tool that exists: drag controls onto a form, double-click, write the handler. Twenty years of Stack Overflow answers, rock-stable, produces one small
.exethat runs on every Windows box in the building. For a form over a database — which most shop tools are — it is exactly enough. - Against: it looks like 2005, custom drawing is painful, and high-DPI scaling on mixed monitors can get ugly. If the UI itself is the product, you'll fight it.
WPF — when the UI is the point
- For: proper layout and data binding, vector rendering that scales cleanly on any monitor, real styling. A live dashboard, a visual tool editor, anything with drawn graphics — WPF handles what WinForms fakes.
- Against: the learning curve is a wall, not a slope. XAML, bindings, and MVVM are a lot of ceremony for a three-screen tool, and a half-learned WPF app is harder to maintain than any WinForms app ever written.
My actual defaults
Python-centric shop → PySide6, packaged to an .exe, and accept the size. .NET shop or IT-managed environment → WinForms for forms-over-data, WPF only when the interface genuinely earns it. And for a one-user utility that just needs three buttons — plain Tkinter ships with Python and needs zero justification.
One more honest option deserves a mention: a small local Flask web app, which is how I built ToolLink. No packaging, no installs — everyone already has the client. The moment a tool needs multiple simultaneous users on different PCs, the web app quietly beats all three desktop frameworks.
Nobody on the floor has ever complained that an internal tool looked dated. They complain when it's down and the one person who understood it left.
Still torn for a specific tool? Describe it to me — I've probably built its cousin.
