Every week there's a new SaaS tool promising to solve a workflow with AI out of the box. Sometimes that's the right call - and we'll tell a client to just buy the tool when it is. But there's a specific set of conditions where a custom-built system is worth the extra investment, and it's worth being precise about them rather than defaulting to either extreme.
Buy when: the workflow is genuinely generic across companies (email drafting, generic transcription, standard OCR), the off-the-shelf tool's accuracy on your specific data is already good enough after light testing, and switching cost if the vendor disappoints you is low. Most horizontal productivity AI falls here - there's no competitive advantage in building your own version of a generic capability.
Build when: the workflow touches proprietary data the vendor can't see or shouldn't see, the value comes specifically from your domain knowledge encoded into the system (a support triage model trained on your actual ticket history outperforms a generic classifier every time), or the workflow is core enough to your business that vendor lock-in on a critical dependency is a real risk.
The messy middle - and where most of our engagements actually live - is a hybrid: a foundation model API from a major provider, wrapped in a custom retrieval layer, prompt architecture, and evaluation harness built specifically around the client's data and failure modes. That's usually the pragmatic answer: don't train your own foundation model, but don't accept a generic wrapper either when the workflow is core to how you compete.
