# Build, Buy, or Fine-Tune AI: A Practical Framework for Founders Source: https://normanholz.de/en/articles/build-buy-fine-tune-ai-framework-founders/ Language: en Last updated: 2025-05-13 Reading time: 5 min read Every AI feature has three paths: buy it, build it, or fine-tune it. Pick the wrong one and you burn money on complexity you did not need. Most AI features do not fail because the model is too weak. They fail because the team picked the wrong path before the first prototype was built. Every AI feature has three basic options: buy it, build it, or fine-tune it. The expensive mistake is treating those options as equally attractive. They are not. Buy is usually the default. Build is sometimes right. Fine-tuning is almost never the first move. Here is the framework I use with founders before they commit six figures, three engineers, and half a year of roadmap to an AI feature that might have been solved with a boring SaaS subscription. ## 1. Buy when the problem is not your moat Your moat is the thing your competitors cannot easily copy. Everything else is plumbing. Customer support automation? Buy it. Meeting summaries? Buy it. Document parsing? Buy it. Basic sentiment analysis on support tickets? Buy it. Invoice extraction? Probably buy it. These problems are not simple. But they are also not unique to you. A vendor with real volume, edge cases, and evaluation data will probably be better at this than your team after three months of experiments. Even if your team can build a working version, that is not the real cost. The real cost is maintenance, monitoring, evaluation, and someone getting paged when a supplier changes their invoice layout. The real cost is your best engineer spending another sprint on a commodity feature instead of the thing that makes your company hard to copy. Buying is not lazy. Buying is focus. ## 2. Build when the feature is the product Build when the AI feature is close to your core value. That usually means one of three things: - You have proprietary data - You have a proprietary workflow - You need a user experience no vendor will care enough to build A trading firm's alpha model is not something you buy from a SaaS marketplace. A legal startup's document comparison engine might be worth owning if it works because of their specific corpus and review process. A medical workflow might need to be built because the value is not just the answer. It is the way the answer is produced, explained, checked, and handed over. This is where "build" makes sense. But build does not mean "train our own foundation model." For most teams, that would be nonsense. In 2025, building usually means: take a strong foundation model, connect it to your product, wrap it in your data, design the workflow, build the evaluation layer, and own the user experience. The model is infrastructure. Your data, workflow, and product judgment are the moat. ## 3. Fine-tune only when close is not good enough Fine-tuning is the option founders love to say and teams rarely need. It sounds serious. It sounds technical. It sounds like progress. Most of the time, it is premature. A fine-tune is not a magic upgrade. It will not fix unclear product requirements, bad data, missing retrieval, or an undefined task. Fine-tune only when all of this is true: - You have high-quality labeled examples, usually thousands, not a few dozen - You have already tested prompting properly - You have already tested retrieval - You can measure the failure clearly - The task is narrow enough that a fine-tune can improve it - You can afford to maintain it when models, data, or requirements change Most teams that think they need fine-tuning actually need better evals. They do not know how good the current system is, where it fails, or whether the failure comes from the model, prompt, retrieval layer, data, or product flow. Fine-tuning before evaluation is expensive guessing. ## 4. Use the boring order Do not start with the most complex option. Start with the cheapest thing that can prove or disprove the feature. For every AI feature, walk through this sequence: 1. Can a vendor solve this well enough? 2. Can a foundation model solve this with a good prompt? 3. Can retrieval close the remaining gap? 4. Can workflow design reduce the need for model intelligence? 5. Is the remaining failure narrow, frequent, and measurable? 6. Is the feature important enough to justify owning more of the stack? 7. Only then consider fine-tuning. Most features stop at step two or three. That is not failure. That is good engineering. The job is not to build the most impressive AI system. The job is to solve the business problem with the least unnecessary machinery. ## 5. Watch out for founder theater The dangerous sentence is: "We are training our own model." It sounds great in a pitch. It sounds like deep tech. It sounds like defensibility. Sometimes it is. Usually it is an expensive way to avoid admitting that the product problem is still unclear. Customers do not care that you fine-tuned a model. They care whether the feature works, saves time, reduces errors, improves decisions, or makes a painful workflow disappear. Start cheap. Measure honestly. Add complexity only when the simpler path has actually failed. Not because it feels more technical. Not because it sounds better in a deck. Because the data says you have to. ## 6. The actual decision rule Here is the simple version. Buy when the problem is common. Build when the workflow is your product. Fine-tune when the model is close, the gap is measurable, and all cheaper options have hit a ceiling. Everything else is ego, confusion, or premature optimization. And those are expensive. If you are mapping out an AI strategy and want a sanity check before committing a quarter of your runway, [that is what fractional CTO engagements are for](/en/).