The other big downside is that when it's custom often there's only one developer you can rely on to work on it.
Not necessarily. That will greatly depend on the language used as well. The 1985 example will be far more limited compared to one nowadays (and when the "stuff" hits the fan when legacy software comes to bite (I remember the surge of interest for COBOL devs (COBOL!!!) in 2020, I told my mom she should apply, she didn't like that one bit). Of course, you have languages like Golang (Go), that are designed to work around that very issue of being beholding to one dev, I would say web apps would be another that use front and back end languages there. I would argue Nim would be the same way (just that's more niche compared to Go).
I would further argue that particularly sign shops that also offer at least web frontend work, should be able to handle something like this. Given Node/Deno as well, wouldn't have to worry about any of the other more traditional back end languages. Using JS/TS would have a huge search results to be able to work through things. I see no differences, between working on tools like this versus looking up search results to fix printers/cutters/computers etc. Or even creating one's own "analog" tools as well (if I remember correctly, we have one active user that has been known to do that) These are all tools that we use, there should be a smattering more knowledge around this so not everyone is beholding to someone else. Or at least be able to spot things earlier. I ironically see more people frankensteining the physical stuff to make things work in ways that they weren't originally designed for by the OEM(or at least when that was more of an option, I doubt this would be so easily doable in the newer models to come) and yet there tends to be a mental block with this. I find that strange.
These are all tools, we should not be hindered by our own tools.
Now, before one starts to think that I'm just an argumentative blowhard on something that is easier said, but not quite so in practice. I have done this. I actually use quote generating tools as my version of a "hello world". I actually have 7 different versions of that (different in terms of the languages used, one of which was from a game engine, so I use what gets things done efficiently for one person doing it). Not full on CRM mind you for every one of those, just quoting and generating a file to send to the client and a more verbose file that's for my records. I actually used an open source CRM as a base and just added what I needed on top of that and self host that. I also have a conversion program for production files written in python, now that is just CLI, but it does what it needs to do.
As things get more to sticking code blocks together (mainly) thru some type of "visual coding" for most things, this will be less and less an excuse. Rather or not, I like that as much, not really, especially if people start off that way (that would be akin to someone starting with Live Trace/Powertrace and not the Bezier Pen Tool). But that's just me. It will lessen the barrier of entry, but I would argue scalability could potentially be a problem, unless it had the ability to handle code snippets and not just doing things along through the visual scripting.
Also with custom software you can't make changes on your own which kind of sucks as a business owner. .
If they have the source code, the ability to have changes done should be there. Rather or not they are the actually ones that does them, that's something else. Depending on what language was used, the barrier to entry for them to make the change, may not be as high as one would think, or for it being hard to find someone to work on it as well.
