Its extremely short sighted. The cost is much more than (hourly wage x code hours).

There is ongoing maintenance cost that no one considers. I've never seen a project that gets built and just sails off for eternity with no maintenance or bugs. There will be times when the libraries or frameworks that built the underlying tool need upgrading. The requirements of the job might change even slightly and need a change in the code because custom tools are always built to only solve the narrow problem.

There is also the overhead of the fact that this junior developer will inevitably leave in 6 months and now someone who has never seen this project before has to pick it up to fix it, which means it will take even longer.

Plus that ignores the fact that if a developer tells you it will take 40 hours it will actually take 80-120 hours.

When you buy, the tools you buy are designed to be integrated with. They have support teams that will help you, and ongoing maintenance. Plus the tool is going to be more robust because it was built and used by many different companies with slightly different requirements. Plus someone else's developers will keep it up to date for you so you don't have to.

Internal tools are almost never worth it unless a pre-existing tool literally doesn't exist which happens when you are either solving insanely complex problems or insanely niche problems.

I'm surprised nobody here mentioned the copyrights yet. By building it, you are gaining the copyright. By buying it, you are gaining a vendor lock-in.

Is it any more shortsighted than using the "open tools" in the first place? There will be integration costs and maintenance of integration with open tools. You may not be able to pay anyone for support issues because those people may not provide the sort of customer support you expect when you pay someone.

> I’ve implemented “buy” for various systems where the work to integrate was essentially the work to build

I've felt this way before, but I didn't realize that I haven't factored in the risks of actually building it. I was comparing real world integration effort with an estimate, influenced by my experience of integrating with a working product.

Common sense applies, but in general I'm terrible at giving estimates unless I've done something very similar before.

Sure it’s shortsighted, but we’re all shortsighted, that’s the human condition. We can’t know all ends, which is why experience and judgement matter. The worst thing you could do is handwring over it though. Gather whatever data you can quickly leveraging the extent of your current expertise, make a call, implement and learn.