Build vs Buy for AI: A Framework That Works Across Fraud, Search, and Support
It's three options, not two
Build vs buy for AI gets framed as "licence a product or build our own." There's a third option in the middle that most teams actually land at: a custom build on proven managed components — a model API, a vector extension, a telephony bridge, an embedding service — without starting from a blank repo or running your own infrastructure. Knowing which of the three you need is the same exercise whether the feature is fraud scoring, product search, or support.
What "buy" gets right
Speed — live in a sprint, not a quarter. Maintained for you. Network effects where they genuinely exist, like cross-merchant fraud signal. No specialist hiring. For a large share of businesses this is the right long-term answer, not a placeholder.
What "buy" costs
- Pricing that scales with your success — per resolution, per transaction, per request — rather than flattening once the system is built.
- A decision surface you can't fully inspect or tune to your business.
- Their vocabulary and rules, not yours — reason codes, escalation logic, relevance model.
The signals that push you off "buy"
- The cost is now large and specific: per-unit pricing at your volume is a real budget line.
- You have proprietary data or business rules the product can't use — "this pattern is fraud everywhere except our standard B2B reorder flow."
- A regulatory burden lands on you: you need to reconstruct and defend decisions with your own versioning and audit trail.
- Latency, deployment, or control requirements the product doesn't meet.
The middle path
Keep the product for the easy 60 to 80% — FAQ deflection, network signal, standard relevance — and build a custom layer for the part where your data and rules decide the outcome. Every project in our portfolio is this shape: a custom build on managed components, not a from-scratch platform, and often sitting alongside an existing tool rather than replacing it.
What building actually requires
The model is rarely the long pole. It's the data pipeline, the integrations, the evaluation harness, the escalation tooling, and someone to own all of it indefinitely. A custom system you can't staff is a depreciating asset.
A quick way to place yourself
- What share of the work needs your specific data or rules rather than a generic capability? High share pushes toward a custom build.
- Is the per-unit vendor cost a real line at your volume, and worse at 2x and 5x? Yes pushes toward a custom build.
- Does a regulator or an auditor need you to reconstruct and defend decisions with your own versioning? Yes pushes toward a custom build.
- Can you staff the ongoing ownership — retraining, monitoring, on-call? Only "yes" makes a from-scratch build defensible over a custom build on managed components.
Run the numbers
Current cost of the problem. Vendor cost at 2x and 5x volume, not just today's. Fully loaded cost of building and owning — retraining, monitoring, on-call, audit tooling. The second number outlives the first, and it's the one that decides it. If the vendor is cheaper at every volume you can foresee and its error profile fits your business, the decision is made; a custom layer enters the picture when the pricing curve or a control requirement makes "good enough for most" not good enough for you.
Where this stops being right
- Low volume or early stage — buy, instrument everything, revisit in a year with real data.
- No capacity to own a build — a custom thing that decays is worse than a maintained product.
- A genuinely commodity problem where the vendor's error profile fits yours — buy and move on.
FAQ
Is "buy" just a stopgap? No. For many businesses a managed product is the right permanent answer. Building is a response to specific pressures, not a maturity milestone.
Can we do both? Usually the best answer — a vendor for the commodity part, a custom layer for the part that's specific to you.
What's the hidden cost of building? Ownership: retraining, monitoring, on-call, and the eval and audit tooling — all of it recurring long after the build is done.
ISTRALLEN builds the custom layer on managed components for teams that have outgrown a general-purpose product — see what we do.