Build the small tool
Say a team wants to check every new SaaS app for risky OAuth scopes. The usual move is a vendor demo, a procurement cycle and a six-figure platform that does forty things. The team needs two of them.
I'd rather build the small tool. A script that lists the granted apps and flags the broad scopes is a day or two of work. A Claude Code skill that runs the same review on request is less. It does one job. I know how it behaves, and when it is wrong I can fix it in an afternoon.
The small tool fits because I built it for the environment. It reads the identity provider we actually use and posts in the channel people actually read. It has no roadmap I don't control and no renewal I have to justify.
I still buy things. Some problems are commodity, and a vendor solves them better than I would. The test I use is simple: can I describe the job in two sentences? If I can, I try building it first.
The cost to watch is maintenance. A small tool still needs an owner and an alert for when it breaks. I plan for both on day one.
Write the two-sentence description of the job before you open the vendor's pricing page.