So low-code is faster to get started with little programming knowledge but isn’t expandable. OTOH, a language and framework that you’ve taken the time and effort to learn takes a little longer to get started but is ultimately more suited to more complex tasks.
I think the takeaway from the narrative here is knowing when to switch from the low code platform and call it a PoC. I’d have cut that off around the point that the custom lambda came into play. That way you’ve used the low code environment for what it’s good at, creating something “they” can react to and easily explore basic functionality. While at the same time you’re taking those learnings and building the more robust solution.
I agree that the main takeaway is knowing when to switch. Having a mental model for this makes many future discussions and decisions much easier, because this seems to be a conundrum that comes up frequently (even for me inside of a large tech organization!).
Based on my experience, I'd suggest the pivot point occurs before even starting: it should pivot around who is building and maintaining the system. If you have the experience needed to quickly develop a solution in code, do it in code. If not, because this is a non-technical team without technical resources, do it in low code. Simple as that.
I usually go straight to the full language. It's pretty hard to find the point when to switch from low code to something else when there is time pressure.
Same with bash vs python. People say you should switch from bash once you have more than 100 lines or so. But at this point you already have some complexity in bash which makes the switch to python non trivial. So you usually end up patching the bash script in small increments as needed. It gets messier and messier but nobody wants to/can spend the effort for a full conversion
Better to immediately switch to Python (or anything else) once you have any non-trivial control flow in your bash script. Loops, non-trivial conditionals, and argument parsing are all easier in Python. Bash is for simple scripts that just chain commands.
Unless you're a regular python user who has already paid the high cost of installing learning to use the whole mess of tools, the break even point exists. There are times when I do the 100+ lines of shell to avoid python. How often do python apps just stop working on me for no apparent reason? (Yesterday I tried to launch puddletag and had to nuke it and reinstall). But for me the big thing is that using "curl | jq | awk" is easy, fast and terse. If I can get away with that I'll choose it every time.
If you're using simple pipes with little control flow, bash is a great choice. Once you need something more complex, you're better off using something else. Not necessarily Python (Ruby and JS work well as replacements, too), but that would be my first choice.
For most simple scripts, Python's standard library is more than enough. File operations, JSON manipulation, HTTP requests and argument parsing are all available without external packages.
Regarding Python apps, have you tried using pipx to install them? That would eliminate most dependency problems, which usually arise from sharing the same environment (potentially including conflicting dependencies) across different apps.
I think the takeaway from the narrative here is knowing when to switch from the low code platform and call it a PoC. I’d have cut that off around the point that the custom lambda came into play. That way you’ve used the low code environment for what it’s good at, creating something “they” can react to and easily explore basic functionality. While at the same time you’re taking those learnings and building the more robust solution.