I've done this kind of conversion, not as a job, but on a case by case basis within my own work. An example would be taking a simple computation that I would sh

I've done this kind of conversion, not as a job, but on a case by case basis within my own work. An example would be taking a simple computation that I would share with people (mostly engineers) in the form of a spreadsheet, and instead turning it into a Python program, even replete with GUI. Here are some of the pitfalls that I've experienced. If I share a computation as a spreadsheet, people already know how to work with the GUI, which is actually quite sophisticated, even if it doesn't prevent you from screwing up. People could extend my spreadsheets, e.g., adding columns to do the same computation on multiple input sets, etc. They could easily extract the output in text format and paste it into something else. And so forth. A Python program with GUI created the expectation that I was writing commercial quality "software," and that if it wasn't 100% intuitive, I would hand-hold each colleague, and make changes on demand, including converters to multiple file formats (often, so they could put the data back into a spreadsheet). And of course I also had to help each person install Python on their computer. Of course I'm not a full fledged software developer, just a "scientific" programmer, and of course the lesson I learned is common knowledge: Writing and supporting real software is orders of magnitude more costly than just writing a one-off program to solve a problem, to the point where the conversion to "proper code" could be a net liability to the business. You have to assess whether it will actually add value. In one sibling comment, it sounds like the answer was yes, so I acknowledge that. The difference was not so much the technology, but the cultural expectations associated with Excel versus "software." Today, I do all of my work in Python, but when I share a simple computation with colleagues, I will often convert it back into Excel for them.