Should we build this with AI at all: build, buy, or skip?
Every AI initiative starts with a decision most teams never make explicitly: whether the problem is actually an AI problem. Get this call right and the rest of the build gets easier. Get it wrong by default and no amount of good engineering downstream fixes it.
What happens at this stage#
The decision to build with AI is rarely made on purpose. It's usually made by default. A vendor demo lands well. A competitor ships something with a chat interface. A stakeholder reads an article. The project then starts from "let's use AI for this" and skips the question of what is broken. It also skips the question of whether AI fixes it better. That order matters more than almost anything that happens later. A system built to answer the wrong question ships on time and passes its own demo. It still gets replaced within a year, because nobody named the problem.
The first real test is whether a deterministic system would solve it. Rule-based logic, a lookup table, a well-indexed database and a decent search bar solve many problems that teams hand to an LLM. They do it more cheaply, more predictably, and without needing an eval suite. AI earns its place when the input space is open-ended, such as free text, ambiguous intent or unstructured documents. It also earns it when the task needs judgment that a fixed rule set cannot encode. If a flowchart could handle the cases you're worried about, build the flowchart first.
If AI clears that bar, the next fork is build versus buy versus skip. Each answer has a real cost model behind it, and that model differs from the sticker price. Buying (a vendor product, an API wrapper) is fastest but caps what you can change later and ties your roadmap to someone else's. Building gives you control. You fit the system to your own data and constraints, and you own the eval suite, the observabilityObservability captures traces of every prompt, retrieval, tool call, and response for debugging. and the on-call. Skipping means deciding not to build anything right now. It's a legitimate outcome, not a failure to decide, and it's the right call more often than most roadmaps admit. Price the free option before you rule buy out. Many infrastructure and tooling products have a free tier big enough to reach a working prototype. We maintain FreeTier as a running answer to that question. Confirm the tier is free and not a disguised trial. That check is faster than building the alternative from scratch.
Cost has to enter this decision before a single line of code, not after. Sticker-price-per-token estimates routinely undercount real production spend by 5–20×, once retries, context growth, and eval runs are counted. A build that looked cheap in a spreadsheet can be the reason the project gets killed at the next budget review. Model the cost of your preferred option before you commit. Use your own expected volume and failure rate. Ignore the vendor's happy-path numbers.
If the decision is "build," you're immediately on one of two forks worth deciding on purpose rather than defaulting into. RAGRetrieval-Augmented Generation (RAG) retrieves relevant passages at query time and feeds them into an LLM's context. versus fine-tuning: do you need to give the model new facts, or teach it a new skill? They're not interchangeable. The other fork is open-weight versus a frontier API, which is really a question of how much operational control you're trading for how much convenience. Neither fork is right or wrong in the abstract. Both go wrong when the team picks whichever it already knows. Pick the one the project's constraints call for.
The common mistake#
The most common mistake at this stage is treating "should we build this" as a formality on the way to yes. Teams skip straight to a build plan without ever writing down the alternative that was considered and rejected. Diligence work on client systems finds this often. A team builds a system. Only a later cost or architecture review shows that nobody priced the deterministic alternative. Nobody priced the real inference costInference cost is what it costs to run a trained model on a request. at volume before committing budget either.
How do you know this stage is finished?#
- You can name, in writing, the non-AI alternative you considered and why it didn't clear the bar.
- You have a cost model for your chosen option, built from your own expected volume and failure rate, not the vendor's per-token sticker price.
- Build, buy, or skip is a decision with a stated reason attached to it, not the default outcome of who was in the room.
- If the answer is build, you know which fork you're on (RAG vs. fine-tuning, open-weight vs. frontier) and can say why.
What backs this up#
Insights
- Build, Buy, or Skip: A Framework for AI Decisions
The framework this entire stage is built on: when building beats buying, and when the right call is neither.
- What an AI Feature Costs in Production
Why the cost half of build-vs-buy needs a real model of your own usage, not a per-token sticker price.
Case studies
- The AI-Native Target That Wasn't: A Two-Week Diligence
What it costs to skip this stage: a diligence pass that finds the real replatform bill after the fact.
Comparisons
- RAG vs Fine-Tuning: Which One Solves Your Problem
The most common wrong turn once "build" wins is teaching a model a skill instead of giving it facts at query time.
- Open-Weight Models vs Frontier APIs: The Real Cost/Control Tradeoff
The other early fork: how much operational control you're trading for how much convenience.
Glossary
- Retrieval-Augmented Generation (RAG)
The default shape for "give the model our own data," and the first thing to understand before choosing RAG over fine-tuning.
- Fine-Tuning (vs RAG)
The other half of the RAG-vs-fine-tuning fork, and what it actually changes versus what RAG changes.
- Context Window
Why "just fit more in the prompt" is a cost decision as much as a capability one.
- Token
The unit every cost and capacity conversation in this stage collapses to.
- AI Register
The register entry a new system needs the moment this stage decides to build it, not once it ships.
- High-Risk AI System
The classification call this stage should make on purpose: it decides how much governance the other five surfaces owe this system.
Tools
- AI Readiness Scorecard
Turn this stage's judgment call into a scored, documented read before you commit budget.
More
- FreeTier
Our own directory for checking whether "buy" is already free before building the alternative.
- Choosing an AI Delivery Partner
If "build" wins and you decide not to build it yourselves, who builds it is its own decide-stage call, with its own checklist.
- The AI Cost Model
The full pillar behind this stage's cost-model requirement above: six surfaces and 24 named levers for pricing your own usage before you commit to build.
- The AI Governance Layer
Classification belongs here, before you build. What a wrong decision would cost is a decide-stage question. Do not backfill it once the system is live.
Questions on this stage#
What comes up before and during decide.
01 How do we know if a problem is actually an AI problem?
Test whether a deterministic system (rules, a lookup table, decent search) would solve it first. AI earns its place when the input is open-ended or the task needs judgment a fixed rule set can't encode. If a flowchart could handle it, build the flowchart.
Link to this answer: How do we know if a problem is actually an AI problem?02 What's the single biggest mistake teams make at this stage?
Skipping the decision entirely. Teams build because a vendor demo landed well or a competitor shipped something, without ever pricing the alternative or naming the actual problem being solved.
Link to this answer: What's the single biggest mistake teams make at this stage?03 Should we use RAG or fine-tune a model?
They solve different problems: RAG supplies facts at query time, fine-tuningFine-tuning trains a model's weights on your own examples, changing its behavior directly. changes behavior baked into the model. Reaching for fine-tuning to fix a knowledge or freshness problem RAG would solve more cheaply is a common version of this mistake. See the full comparison.
Link to this answer: Should we use RAG or fine-tune a model?A Ship Audit checks your actual system against every stage of this handbook and hands back a written, prioritized plan.