Most owners frame the AI decision as buy or build, and for most businesses the right answer is neither: it’s a proven, ready-made model connected to your own data and systems. Here is the question that sorts the three options, a worked example, and the traps that waste the most money.
The one question that sorts buy from build
Every AI purchase we’ve reviewed comes down to a single question: does the value come from the AI knowing your business, or from it doing something everyone needs? If the job is the same for every company, someone has already built a good tool, so buy it. If the value depends on your data, your processes, and your systems, no ready-made tool will fit, and you build the connection. Not the model, the connection.
flowchart TD
A(["What do you need AI to do?"]) --> B{"Common need, the same for everyone?"}
B -->|Yes| C(["Buy a ready-made tool"])
B -->|No| D{"Does the value come from your own data and systems?"}
D -->|No| C
D -->|Yes| E{"Is the model itself your product?"}
E -->|Almost never| F(["Connect a proven model to your business"])
E -->|Yes| G(["Build or train your own model"])
The third branch is rare: training your own model is for companies whose product is the model. For everyone else, the models from Anthropic, OpenAI and Google beat anything you could train, and the work is in the wiring.
Buy a ready-made AI tool when
- The need is common. Meeting notes in Teams or Zoom, a writing assistant, a coding assistant like GitHub Copilot, basic analytics in the BI tool you already have. Thousands of businesses need the same thing, so vendors have already paid to get it right.
- It fits without bending your process. If you can switch it on and use it as designed, buy it. A subscription you can cancel next month is a cheap experiment; a build is not.
- The job is not part of your edge. Nobody picks your company for its meeting transcripts. Buy the commodity; spend engineering money where customers notice.
The catch with ready-made tools is what they do with your data. Ask where it’s stored and processed, and whether it trains the vendor’s models. PDPL took effect on 14 September 2023, full compliance was required by 14 September 2024, SDAIA is the regulator, and cross-border transfer is governed by Article 29 and SDAIA’s Transfer Regulations (Morgan Lewis, 2024). A tool that quietly ships customer records abroad is a compliance problem you bought, not a productivity gain.
Build the connection when
- The AI has to work with your data. Your contracts, price lists, ticket history, ERP records. A generic tool doesn’t know your delivery terms or your biggest customers, and the value is precisely in knowing them.
- The workflow is what makes you special. If the thing you’d automate is how you quote, underwrite, or schedule crews, that process is your edge. Don’t hand it to a tool that does it the same way for your competitors.
- Fitting a ready-made tool is a build in disguise. When the vendor’s “configuration” runs to months of consultants and custom scripts, you’re building anyway, on someone else’s platform and exit terms.
- You need control over the data and the results. Who sees what, where it lives, what happens when you leave. In our experience this decides it for regulated businesses: a bank under SAMA, a clinic connected to NPHIES, a supplier bidding through Etimad.
Build vs Buy: When Custom Software Beats Off-the-Shelf covers the general software version; the AI version has one twist.
The middle ground, where most of the value lives
It’s rarely pure buy or pure build. The most valuable AI for most businesses is a ready-made model connected to your specific business: a proven, world-class model used through its API, plus a layer you build that feeds it your data, your rules, and your systems. The common pattern is called RAG, retrieval-augmented generation: the model is handed the relevant pages at the moment it answers. You’re not building the AI, nobody should. You’re building the connection that makes a general model useful for you.
flowchart LR A(["Your systems: ERP, CRM, documents"]) --> B(["Connection layer: retrieval, rules, permissions"]) B --> C(["Proven model, via API"]) C --> D(["Draft answer or action"]) D --> E(["A person reviews the exceptions"]) E -->|writes back| A
The connection layer is four boring things:
- Retrieval. Your documents and records, indexed so the model gets the right five pages, not the whole archive.
- Rules. The logic the model must never guess: pricing floors, approval thresholds, what it’s not allowed to say.
- Permissions. The model sees only what the person asking may see. This is where PDPL compliance is actually enforced, in the wiring, not in a policy document.
- Review. A person on the exceptions, especially early. The model drafts, the human signs.
In our experience this is faster and cheaper than owners fear, and it’s the piece vendors least like to explain, because it’s where the margin is. The data side has its own post: Using Your Company’s Own Data With AI, Safely.
A worked example: the quotation desk
Say your sales team produces 400 quotations a month. Each takes about 45 minutes to assemble: checking stock, price lists, the customer’s contract terms, and last year’s discount. That’s roughly 300 hours a month. The numbers are made up to show the shape.
Buy: a general writing assistant. It makes the emails nicer and saves perhaps 5 minutes a quote, because it knows nothing about your prices or customers. Call it 33 hours saved for a small subscription. Cheap, and almost pointless.
Build from scratch: a vendor proposes training your own model on your quotation history. Long timeline, large budget, and by the time it ships the general models have passed it.
Connect: a proven model wired to your ERP for stock and prices, your CRM for contract terms, and your last three years of quotes. It drafts the full quotation; a salesperson reviews and sends. Say a quote now takes 12 minutes, so about 80 hours a month instead of 300. A one-time build, a modest monthly run cost, and a person reviewing every quote until the error rate earns trust.
The generic tool does almost nothing specific; the from-scratch build reinvents what you could rent. The connected option costs more than a subscription and far less than a model, and it’s the only one where the saving is big enough to matter. The full build-and-run breakdown is in What Does It Cost to Add AI to My Business?.
Where this goes wrong
Two big ways to lose money, and smaller ones.
- Paying to “build custom AI” for a commodity job. If the need is common, a build is pure waste: months spent arriving at something a vendor sells for a monthly fee. Watch for proposals with “custom” in the title and meeting transcription in the scope.
- Forcing the business into a tool that almost fits. Cheap on day one, expensive forever: workarounds, side spreadsheets, staff who quietly stop using it. Gartner has said for years that a large share of ERP initiatives fail to meet their intended business goals; the AI version is a licence everyone pays for and nobody trusts.
- A “custom” build that’s really a thin wrapper. A chat window over a public model, with none of the retrieval, rules, or permissions above, priced as bespoke. Ask where your data enters the system. If the answer is “in the prompt”, you’re paying build prices for a subscription.
- Ignoring the run cost and the exit. Usage fees, hosting, and the human on review are monthly costs. And a tool that holds your data in a format only it can read has an expensive cancellation fee.
This is what drives the abandonment figures. Gartner predicts at least 30% of generative AI projects will be abandoned after proof of concept by the end of 2025, due to poor data quality, inadequate risk controls, escalating costs, or unclear business value (Gartner, 2024). Escalating cost and unclear value are what a wrong buy-or-build call produces.
How to start
The pattern that works is boring and reliable. Pick one job where the answer to the question above is clearly “our own data”. Measure what it costs you today in hours, honestly. Run a small, contained pilot: a proven model, wired to one system, with a person reviewing every output. Measure the net saving after build and run costs, not the gross. If it pays back, scale it to the next job. If it doesn’t, you’ve spent a little to learn something cheap.
For the commodity jobs, buy the tool, check where the data goes, and move on. The owners who win with AI buy the common things quickly and build the connection where it counts.
Not sure whether to buy or build? SDCG gives owners independent build-vs-buy advice, and because we’re the engineers who’d build it, we’ll tell you honestly when a ready-made tool is the smarter, cheaper choice. Our AI strategy and proof-of-concept work starts here. Book a free 30-minute review.