Consultancies have an obvious incentive to tell you to build, and vendors have an obvious incentive to tell you to buy. Since we price on measured outcomes rather than billable hours, we make more money when the answer is right than when it's "build." Here is the framework we actually use in scoping calls — including the third option nobody sells.
The three questions
1. Is this problem core to your margin?
If the capability directly sets your prices, your costs, or your conversion rate, its performance compounds into your P&L every day, and a 2–3% edge over the vendor-average solution is worth real money. If it's a supporting function — transcribing calls, OCR on invoices — the last few percent of performance are worth almost nothing to you. Build candidates are margin-core; everything else defaults to buy.
2. Do you have a data advantage a vendor can't have?
Vendors win on generic problems because they see more data than you ever will: a speech-to-text vendor has millions of hours of audio. But on your problem, you may hold data no vendor sees — your guests' booking histories, your production line's defect images, your platform's user-behavior trails. If your proprietary data would make a model meaningfully better than one trained on market averages, that's a build signal. If a vendor's aggregate data beats yours, buy.
3. Is off-the-shelf actually good enough — measured, not assumed?
This one requires a test, not an opinion. Run the tool on a holdout of your real data and measure it against your current method. Two outcomes are informative: the tool wins clearly (buy, done), or you find your team constantly overriding it — and each override is domain knowledge that a custom model could learn. Chronic overrides are the strongest practical build signal we know.
Worked examples
Dynamic pricing for short-term rentals
Margin-core: yes — price is the margin. Data advantage: grows with portfolio size and property atypicality. Off-the-shelf: genuinely good for typical properties in liquid markets.
Our honest recommendation: under roughly 15–20 listings, buy a tool (PriceLabs, Wheelhouse, Beyond) and spend your energy operating it well. Above that — or with atypical properties where market comps mislead — a custom pooled demand model starts paying for itself, because small per-night gains multiply across hundreds of bookable nights. We wrote in detail about why generic demand forecasts fail on seasonal properties.
Review fraud detection for a marketplace
Generic fraud tools model generic fraud: velocity checks, device fingerprints, template text. They miss what's specific to your platform — coordinated review rings in one category, seller-funded incentivized reviews, timing patterns around your own promotions. That specificity lives only in your data, which is a data-advantage argument to build. The catch is labels: a fraud model needs confirmed fraud cases to learn from, and building the labeling process is often half the project. Buy first to handle commodity fraud; build the domain-specific layer when the generic tool's misses become measurable in dollars.
Customer support automation
Almost always buy-then-configure. LLM-based platforms are commoditizing fast, and the value is in your knowledge base, escalation design, and integration — configuration work, not model work. Build only the thin layer that touches your systems. What matters here is measurement discipline: track resolution rate without human handoff and cost per ticket, or you'll never know if the tool earns its subscription.
The costs nobody puts on the slide
| Cost | Build | Buy |
|---|---|---|
| Upfront | Commonly $20k–$50k for a scoped problem with clean data; $100k+ when pipelines, integrations, or labeling must be built (industry-typical ranges) | Low — subscription and onboarding |
| Ongoing | Roughly 15–30% of build cost per year: monitoring, retraining, drift fixes. A model without a maintenance plan is a depreciating asset | Subscription scales with volume — cheap at small scale, can exceed a build's total cost at high volume |
| Hidden | Data access negotiations inside your own company (often the real schedule risk) | Lock-in: your tuning, overrides, and history usually don't export. Switching later means starting over |
| Exit | You own the model and the learning | The vendor owns the learning your data paid for |
The third option: neither
If decisions are infrequent, data is small, and a human reviews every decision anyway, the honest answer is a spreadsheet or a handful of rules. A weekly pricing review over ten units does not need a model. "Flag reviews from accounts under 30 days old with more than three reviews" catches a surprising share of fraud with zero ML. ML earns its cost when decisions are frequent and high-volume enough that per-decision human attention is impossible — hundreds of nightly prices, thousands of transactions, real-time routing.
Our ML ROI calculator includes exactly this diagnostic: it will tell you "spreadsheet," "buy a tool," or "custom model territory" based on your decision frequency and volume — before any numbers about us enter the conversation.
Why you can trust the "don't build" answers on this page: NexoLogic charges no upfront fee and takes a share of measured improvement — so recommending a build that won't pay back costs us money directly. If a scoping call ends with "buy the off-the-shelf tool" or "use a spreadsheet," that's the framework working. How our pricing and Founding Client Program work. Where we focus: freight and logistics, retail and grocery, and energy and utilities.