Makes sense, that's what I've seen other folks do. I'm curious if you've seen them ask for more features over time, more actions, ability to manage the rules they write - and whether the full blown version of what they need was easy to support?

There's definitely room for growth - when has the business never asked for more haha. It's Agile were I work, so... Generally we deliver the basic UI with functionality to change one field/setting. See how they like it while we start working on the other fields. Assume they want more than they initially ask for because they overlook the details, like audit history and reporting stuff for example. And we obviously build in some basic logic/input constraints so people aren't entering unrealistic stuff.

Overall, it depends on the system if it saves time/effort or not. If the changes are infrequent and basic, you might as well just have them send an email and plug it into an SQL template that you saved from the last request. If it's repetitive and frequent, then I think it makes sense to build a simple UI and let them deal with it.

It could also depend on what you like. You mention wanting to build system over changing business logic. So maybe you would like building the system for them to make thier own changes vs making updates yourself.

I do feel you om the business logic stuff. I'm currently dealing with a problem because of the business requests. They commingled business display content and system data in one field, then the other team decided they would change that field content per the business request without consulting with downstream systems. Not to mention they aren't properly following json format so we have to do some escaping/parsing before running the message through a real parser... it's so frustrating. And of course the pressure is on me to fix it, and my suggestion to roll back that change the broke multiple systems was a no-go. Apparently form is more important than function.

Thanks for sharing your story. Oh man, that sucks! Yeah, it's funny there's things I don't want to build in the first place. And then the moment you build them, you are responsible for making sure they work for the rest of your tenure. Managing downstream dependencies is genuinely hard for so many systems, and is made worse by the lack of visibility and custom code-writing for internal tools.

I actually would love to own a system. I've done that as an acting tech lead for a year, and then as an ASC for a large application from a security perspective. It seems that the issues in this system are different. I probably should have said no to building it until the other systems fixed their architectures (comingled business and tech data, really?). I don't know. I need a job so I should just keep my mouth shut. I wish I could be the one making those bigger decisions and making lots of money while sucking.