Most teams scope an AI workflow and reach immediately for "build." A custom application, a custom model, a custom integration layer. Six months later they're still trying to ship the first version, while a competitor stitched together two SaaS tools and a Zapier-equivalent and has been running it in production since week three.
Custom is sometimes the right answer. It's almost never the first answer. Run the workflow through three questions before you commit.
Question 1: Is this a core differentiator?
If the workflow is something a customer would pay you specifically for, and the way you do it is part of your competitive position, building has a case. If the workflow is internal triage, drafting, summarisation, classification, or any other "every business does this" category, the answer is no, and "no" eliminates ninety percent of build cases on its own.
Question 2: Is there a SaaS that does eighty percent?
Eighty, not a hundred. Perfect-fit SaaS is rare; eighty-percent-fit SaaS is everywhere. If a vendor covers the workflow with one or two visible gaps, buying and tolerating the gaps is almost always cheaper than the build that closes them.
The trap here is letting a beautiful PoC obscure the cost of operating the custom thing on day 200. Vendors operate their own products. Your team does not want to operate yours.
Question 3: Can two or three tools, stitched, get you to a hundred?
This is the option most teams skip. A SaaS for the data layer, an LLM API for the language layer, a workflow tool for the orchestration. Each piece is owned by a vendor. The thing you're building is the integration, which is small and replaceable.
Most of the workflows we ship live here. Stitched solutions are fast to build, easy to swap, and give the team a path back to manual when one of the pieces fails. Build is the last resort, not the default.
The cheat sheet
- Differentiator + no SaaS exists yet. Build, but scope it as the smallest possible thing.
- Differentiator + SaaS at eighty percent. Buy. Wrap. Stitch the gap.
- Not a differentiator + SaaS exists. Buy. Stop arguing about the gap.
- Not a differentiator + no good SaaS. Stitch.
Most "we have to build it" arguments are smuggled-in preferences for the elegance of building. The customer doesn't care.
This filter saves engagements weeks of design work. It's also why our Implement work doesn't always end with a custom system, sometimes it ends with three tools wired together and a clean SOP.