See the process first

A shell script often begins with a small irritation. Three commands have to run in the same order, a directory has to exist first, and at the end a file should land in the right place. After the third time, the thought comes quickly: a script can do this.

Most of the time, that is true.

It becomes dangerous one step earlier. If it is not yet clear which steps actually belong to the process, the script does not automate the process, but the confusion around it. After that, the confusion looks more stable because it has become reproducible. From the outside, an error that repeats reliably looks almost like a process.

The first useful step is therefore often not automation, but observation. Which input changes the result? Which check catches an error? Which part is still manual work because no judgement can yet be formulated for it? Only when those places have been named is it worth putting them into code.

That is not an argument against larger systems. Some processes really do become larger over time: more cases, more states, more responsibility. Then the script may become a tool. Its growth should come from the observed mechanism, not from the wish that a simple procedure would finally look like architecture.