Automating a broken process just scales the problem. And automating one that doesn't exist yet is even worse.
A client once asked me to build an AI agent for something their business had never actually done.
Meaning there wasn't an existing workflow. They wanted me to automate an idea. An invention.
That's a rough spot to be in.
When you automate a proven process, you're making something that already works faster, but when you automate an invention...
→ The fingers point at you if it doesn't help the business. Even if your build was good.
A lot of builders take these projects anyway. The client hands over the requirement, you want to win the work, so you say yes.
But if the process is broken or made up, all the automation does is help it fail faster.
Automations don't tell you when they're wrong. Evals do. And evals need a golden dataset: a set of known right answers to grade against.
So before you build something, make sure you can collect a golden dataset of correct runs of the system. Make sure that data actually exists.
This is also the case for buying before you build. Why not start with something off the shelf?
Maybe it's a $20/month tool, maybe it's $100. Buy it, use it for a month, and pay attention to what you like and what drives you crazy.
By the end you've basically written the PRD for your custom build, because you've actually lived the process instead of guessing how it will work and fail.
I'm not saying you should never build custom. I'm saying buying first lets you run a proven, supported version of the process, so when you do build your own, you know exactly what you want it to do.
Go make it work with a human first, then come back and make it fast.