Build only the secret sauce, buy the rest
The most expensive habit I see in AI work, my own included, is building things that were available off the shelf, because building them is satisfying and the first version is deceptively quick. The market moves faster than any internal build, and most of what feels like your special capability is a commodity someone already runs better than you will. So before any new capability enters a build loop, I run it through a gate, and the gate has two axes, not one.
The first axis is the familiar one: build, integrate, or a hybrid. The default answer leans harder toward buy than my instincts want it to. A concrete example from my own system: I needed cross-model review, having a second model from a different lab critique work before it merges. The instinct is to build a harness for it, wire up the API, manage the orchestration. The right answer was an off-the-shelf review app that runs on a subscription I already had, summoned with a comment. Zero build, flat cost, and it does the job. Checking the market first turned a project into a one-line integration. The test I apply is whether the thing is genuinely my secret sauce, the part that's specific to my problem and where doing it well is the actual advantage, or whether it's undifferentiated plumbing that a vendor has already solved and maintains for a living. Plumbing gets bought. Only the secret sauce gets built, and most things are plumbing.
The reason this needs to be a deliberate gate rather than a gut call is that the gut is biased toward building. Building is legible progress, you can see the thing take shape, and the first 80 percent comes up fast in a demo. What the demo hides is the long tail: the maintenance, the edge cases, the security, the fact that you now own forever a thing that wasn't your differentiator. Retrieval is the classic trap. It's tempting to build a whole pipeline, and for most corpora the right answer is to use the model's context window with caching, or a database extension you already run, precisely because a full custom pipeline is cost you'd be signing up to maintain for a capability that isn't your edge.
The second axis is the one most people don't separate out, and separating it is where the real leverage is: not just what to build, but when to automate. A capability can clearly be worth having and still not be worth automating yet. The two questions are independent, and collapsing them is how you end up building an elaborate automated pipeline for something you've done by hand exactly twice and don't yet understand well enough to automate correctly. So the second axis is automate-now versus do-it-by-hand-now. Doing it by hand first is how you learn the shape of the problem before you commit code to it. You run the thing manually until you actually understand where the judgement lives and where the drudgery lives, and only then automate the drudgery, keeping the judgement where a human still adds something.
Doing the manual version first has a second payoff: it tells you the seam. When you've run a task by hand a handful of times, you can see exactly which step is mechanical and repeatable and which step is the bit that actually needed you. Automate before you've found that seam and you'll either automate the judgement (and get confident wrong answers at scale) or build rigid machinery around a process you didn't understand and have to tear out. The manual passes are cheap tuition. The premature pipeline is expensive rework.
Run both axes and you get four honest outcomes rather than the single default of "build it and automate it," which is where enthusiasm lands you every time. Buy it and use it as-is. Buy it but wrap it in your own judgement for now. Build it because it's genuinely your edge, and automate it because you understand it. Or build the thin version and run it by hand until the seam is obvious. The specific answer matters less than the discipline of asking both questions before writing anything, because the failure I keep watching, in my work and in transformation programmes generally, is smart people building undifferentiated infrastructure with obvious enthusiasm, and automating processes they hadn't yet earned the right to automate. Check the market first. Build only the secret sauce. Automate only what you've already done by hand enough times to understand.