Most enterprise platform customisation is written by hand, deployed by hand, and documented in the memory of whoever wrote it. That is not laziness. The platforms make the good practices awkward: the runtime is proprietary, the module loader is unusual, and there is often no local environment at all.
So the work gets done without tests, without a pipeline and without written reasoning, and it works. Then the person who wrote it moves on, and a system that was perfectly maintainable becomes a system nobody will touch.
What I do differently, and what it costs
On a platform application I own, the stack includes four unit test suites, a continuous integration pipeline, bootstrap scripting for the infrastructure and six documentation files. On the module side, a specification was written as business rules, trigger points and acceptance criteria before the code, and the money paths were validated against a real payment gateway before any live record was touched.
The cost is real. Making platform scripts testable means pushing logic out of the parts that touch the runtime and into functions that take data and return data. That is more files and one more layer than the obvious version.
Where it pays
Logic you cannot provoke on demand
A retry ladder, a proration calculation, a compliance window that needs a distinct completed visit rather than a count. You cannot wait for these to happen in order to check them, and you certainly cannot wait for them with real money involved. In a test they are a few lines of setup.
The second deployment
Deploying by hand is fine once. The risk is the fourth change under time pressure, when a file gets missed and the two halves of a system disagree. A pipeline removes the class of incident where the code is correct and the deployment was not.
Rollback as a written step
A documented single step rollback is worth more than any test. When something is wrong in production, the question is not what broke. It is how fast you can get back to the state before. If that answer involves reconstructing anything, you do not have a rollback, you have a hope.
One shared library, two entry points
A specific thing worth stealing. An application of mine has two ways in: a path served from the platform and a service on managed infrastructure. Both read and write through one shared library.
Without that, the two paths drift. A fix lands on one and not the other, and six months later they behave differently in a way nobody can reproduce because it depends which door you came through. One library makes the drift impossible rather than discouraged.
On working with AI tooling
I use AI assisted workflows heavily and I will say plainly what that does and does not change. It moves faster through the parts that are typing. It does not own the architecture, and it does not read the output for you.
I read every line that ships. The practices above are what make that possible at speed: if the logic is in testable functions with a specification next to it, reviewing generated code is a focused job. Without them, velocity is just a larger pile of code nobody has read.