I get that sometimes automation sets you on a course of infinite refinement, and you end up investing more money that you should have making some tool cover 100% of all possible use cases. But that doesn't mean you never should have started building the tool, just that you went way too damn far once the "bugs" and "feature requests" came rolling in.
What about the relative costs and risks associated with hiring a workforce for all the manual labor? There's a certain net weight in work that needs to be done, you can shovel it by hand or you can build a machine to help you. How is it not a winning move to hire fewer, smarter people, and empower them with a great software stack?
The goal isn't to build a machine which can do 100% of the work. But whatever the product you sell, you may find you can spend $1 in engineering to reduce the variable cost of delivering that product by more than $1. That's printing money. But to identify these opportunities, and more importantly to prioritize these opportunities and stop working on the BS never-pay-you-back feature, I think you need a project manager who can understand software complexity as well as the business case.