Empower your clients to make changes
When a client asks me to make a change to a website, I have two choices. I can go and make the change. Or, I can set things up so that the client can make the change themselves.
It's not always obvious which of these two will be a better use of my time. If it's a one-time change that will never need to happen again, of course it's better if I go make the change. But sometimes it's obviously something that will need to be changed again and again.
Sometimes the change is so small that it's a quick copy & paste, so there's almost no benefit to adding a content management system. Often, the changes can be more complex, and require a lot of back-and-forth communication, asking for clarification, testing, reviewing, etc. I have a pretty low tolerance for this before I insist on building a tool for my client instead.
Pretty much every system should have some kind of administrative login area, where the client can go in and access these admin-only tools. It might be as complex as a content management system, where they can create whole new pages, and change all the text in the system. It might be where they manage other users, or get the answers to questions they might have otherwise asked me for.
In one case, I had built a system that had a complex set of rules, basically if/then statements, and it was evolving rapidly. Every week I was being asked to make changes to the logic, and also asked to remind the client about what it was already doing. So, in a few days, I designed and developed a Domain-Specific Language (DSL) that allowed all of the logic to be captured in a single text file. It wasn't a programming language, because my client isn't a programmer. Rather, I designed it to be intuitive for him, so it would be easy for him to read, edit and publish changes to the logic in the system. Many years later, he is still actively working with this same DSL.
I have another client who is more technical, and has some experience with basic HTML and CSS. They wanted to make broad changes to the design of the site, and to the text that was hardcoded throughout. I gave them two options: either they could provide me with a long list of these changes, or I could bring them in to collaborate on the code. They had no experience with git, GitHub, Svelte, or even with using an IDE. I thought it was worth a try, so I sent them a long list of instructions for installing all the software they'd need. I sent them a few YouTube videos about using VS Code with Git, and had them create a GitHub account. I explained how the site was architected, and the basics of Svelte components.
Within a week, they were making changes to CSS and text and committing and pushing changes to GitHub! It was so exciting! Just looking at the long git diff, there were literally hundreds of changes. If they had tried to write out those changes in a Google doc, it would have required dozens of screenshots. It honestly would have been painful for me to carefully go through and implement all of the tiny changes. And chances are, I would have screwed up more than once, and they would have had to make new screenshots. They would've felt like a bother to ask me to increase the font size by 5%, or change a border to a different shade of grey. More than likely, they would have just accepted my poor attempt as "good enough" and said thanks.
Instead, they are now empowered to go in and make changes themselves whenever they want. As the site evolves, over the coming decade, they'll have the confidence to go in and make all the updates they need. They were even able to use AI to generate a snippet of Svelte code in order to add a second button to the page!
No, I'm not worried about my job going away. I'm happy to be focusing on the hard things, and empower my clients to do as much as they can on their own. They are delighted to not have to "bother me" for small changes when I'm working on bigger features for them. They're able to save money and time. It's truly a win-win.
Another client had a very complex system that was built by a third-party vendor and written in Python. They brought me in to help simplify the system. In this case, they actually did have developers on the team, but the developers didn't have much Python experience. I actually rewrote the entire system in TypeScript. It was a fantastic opportunity to clean things up and simplify. I wrote it in a way that it would be intuitive to them, so the training only took an hour or two. I was delighted to see the developers confidently making changes to the system themselves for the first time ever, and with ease.
A Chinese proverb says, "Give a man a fish, and you feed him for a day. Teach a man to fish, and you feed him for a lifetime." I say, "Make a change for a client, they'll be happy for a day. Empower your clients to make changes themselves, they'll be happy for a lifetime."