Buy a tool
Right when your process resembles everyone else's. Support inboxes, meeting notes, transcription, generic document extraction: these are solved products, and building your own is usually vanity.
It fails at the integration boundary. The tool cannot see your systems, so someone becomes the human API between them, copying output from one screen to another. That is where adoption dies, and it is why a team that "already tried an AI tool" often concludes the technology does not work when the tool never touched their data.
Build in-house
Right when the automation is close to your product, when the domain knowledge is hard to transfer, or when you already employ engineers with capacity. Cheapest at steady state and the only option that compounds internal capability.
It fails on time-to-first-value and on the unglamorous parts. Teams underestimate evaluation, monitoring, retries and cost control, because those are where LLM systems differ most from ordinary software. A first project also carries a learning curve someone has to pay for.
Hire a studio or contractor
Right when you want the first workflow live in weeks rather than quarters, when you have no one to hire, or when you want the pattern established before your own team takes it over.
It fails when it produces a black box. If the code sits in someone else's account, the prompts are undocumented and there is no evaluation set, you have rented a result rather than acquired a capability. That is the failure mode to write out of the contract.
Ask any partner these five questions
- Where does the code live, and whose accounts hold the infrastructure?
- What does the evaluation set look like, and do we keep it?
- What is the running cost per transaction, not per month?
- What happens when the model provider changes versions?
- Which parts stay manual, and why?
Vague answers to any of those predict the same outcome: a system that works during the engagement and decays after it.