Yes! After posting I started thinking about this a bit more. As tamte wrote I would also do it, and make sure the HDA is available to all artists. This is basically how HDAs should work. However, you could put all your code in that HDA, even as hidden
Alternatively, if you do not want to include the code in the actual HDA you could use the script node to read files that you could place next to the HDA file location or somewhere accessible. Actually that node is not even needed. In my shelf I have one import button that will read my entire "generic" module that hold most of my scripts that are not supposed to be included in any HDA. It will also copy necessary scripts to nodes if needed. The shelf buttons only make calls to various functions in that code (because I do not want to spread out my "source" code everywhere). A single button could both include and run a function also. It just depends on how you like your work to be (as long as you solve the core problems and needs I guess). As a side note, in my real job (this is not) my choice of methods will basically determine my own stress level and the amount of related issues that will show up, so finding methods that keep that under control is recommended.
Additionally it is very recommended to start new things in a long term direction, because it is not effective to have to redo things almost from scratch. If things are very basic in the beginning does not matter, with some time it will be possible to improve it. Knowing that what you do will be used for a long time adds to your motivation to do it as well. The opposite is also true.
In the UI parm editor (promoted parms) there exist a bunch of useful things, for example drop down menus. I could easily imagine you provide just a drop down list for artists, and based on the choice there will be different checkboxes, sliders, node selections and whatever. Then the "run" button will then execute whatever code is chosen and the settings. The settings can just be sent as arguments (or parameters if you prefer) to your functions.
There might be a lot of learning involved, but if you can just get something barely working out there then you can upgrade in small steps over a long period. That is usually how I like to do things.
Edit: However you do it, as I had to learn from someone to not forget the arguments, I would consider not only running scripts but also making some settings related to each of them. Just "running" scripts is too basic. Alternatively, you can make your code "context aware" so that based on what is selected and found by the code, different changes are done.
Edit2: Here's how I import my generic module. It just works, however it is not built for a network, however that is simple.
from os.path import join
from sys import path
from importlib import reload
#hipFilePath = os.path.dirname( str(hou.hipFile.path()) )
# mymodule_dir = os.path.join( hipFilePath, '..', 'a', 'b' )
# myModuleDir = os.path.join( hipFilePath, 'py' )
myModuleDir = join( '/home','username', 'houdini19.0', 'py', 'generic' )
path.append( myModuleDir )
hou.session.generic = generic
# just a typical button
IT-teacher (8y) / just for fun TD & artist / Debian11 XFCE / Houdini / Zbrush (Wine) / Blender / Python / VNC / networks / two small kids / BSc CS:CG / Stockholm