Fine-Tuning vs. Prompting vs. RAG: When to Use What

Every week a founder DMs me the same question in three variations: "Should I fine tune GPT 5 on our support tickets?" "Do we need a vector database?" "Is prompt engineering still a thing in 2026?" The answer is almost always the same, and it's almost always the opposite of what they were hoping for. Most builders reach for fine tuning because it sounds serious. It has the word "training" in it. It feels like real ML work, the kind that justifies a $40k GPU bill and a slide in the pitch deck. RAG feels like plumbing. Prompting feels like cheating. So they skip the two things that would ship in a week and spend three months curating a dataset that, when they finally run the eval, performs worse than a well written system prompt against Claude Opus 4.7. This post is the framework I wish someone had shoved in my face in early 2024. It's opinionated on purpose. If you're a solo founder or a two person team trying to ship something before your runway evaporates, read it in that order: prompting first, RAG second, fine tuning almost never. Prompting is the default, and you are probably not done with it The current frontier models — GPT 5, Claude Opus 4.7, Gemini 3 Pro — are absurdly good at following instructions when you actually write them properly. "Properly" does not mean "You are a helpful assistant." It means a system prompt with a role, a task, hard constraints, an output schema, two to five few shot examples, and a refusal clause. That is 800 1500 tokens of prompt. Nobody writes them. I audited a friend's SaaS last month. His "AI classifier" was a 63 token prompt that hallucinated categories 22% of the time. He was three days into planning…