Buy, configure, build, borrow. In that order.
There are four ways to get a capability and the default is not build. A company decides where its own engineering goes, and the honest answer is almost always the one or two things that are the reason anyone picks it. Everything else gets bought, configured, or borrowed. AI making software cheap to write has made this harder to hold, not easier, because now everyone can build the thing they should have bought, in an afternoon.
Decision rights
The call is made per capability, at company level, and it outranks team preference. The preference is real and it always points the same way: engineers would rather build, they can now build fast, and neither of those facts says anything about whether building is right.
One question settles most cases. If this were free to buy tomorrow, would we still want to own it? If yes, it is differentiation. Build it. If no, you were enjoying yourself, which is fine to notice and bad to ship.
Memory and context
Decide on cost to own, not cost to build. Building is now the cheap bit. The expensive bit is every dependency upgrade, every framework change, and every person who leaves knowing how the thing works. A tool an agent wrote in an hour still needs a test, a home, a reviewer, and someone who remembers it exists.
Buying has the mirror-image cost and it is invisible on day one: what it costs to leave in three years when your data has moulded itself to their shape. Write the decision down with its reason, otherwise it gets re-argued every eighteen months by someone who was not there the first time.
Execution
Build the thin thing, buy the thick thing. The custom part of most systems is small and sits on top of something large that somebody else maintains. Teams get this backwards, building the big boring foundation and buying the small part that was their actual edge.
Configure is the option that gets skipped and it is often the answer. A bought tool bent to your process is neither the fight of building nor the compromise of taking defaults, and for a company that has not yet earned a custom system, that is where most of the value is.
Borrow is its own thing, not a polite word for "we used a library". Borrowing is taking someone else's pattern, agent, or open codebase and running it as yours. Fastest of the four, least support underneath it.
Governance
Every built thing carries a named owner and a written reason it was not bought. Anything with neither is a deletion candidate, and deletion should be routine. The pile of internal tools is made of things that were each individually reasonable.
Reasons expire. "We built it because nothing existed" is true until the market catches up, and then the honest move is to migrate, not defend the investment. Set the review date when you make the decision, or nobody revisits a system that works.
Borrowing carries one governance question the other three do not: what happens when the thing you depend on gets abandoned. Ask before, not after.
Observability
The number that matters is the share of engineering time spent on things that are not the reason anyone chooses you. When most of it is, the portfolio decided itself while everyone was busy.
The tell that a build was wrong: nobody can name the alternative that lost. A real decision has a loser. If the team cannot say what it was, no decision was made, the work just started.