Build vs Buy

For a developer, it might look "easier" because literally anything could be built by coding if there is no limit on the time and money they can spend.But for a company, this means more to them. Of course, they can build anything but there is something called "opportunity cost". A CPO or a CTO or the leadership thinks differently compared to a software developer. The decision is between "whether we should build this feature and add one more potential point of failure

# RequirementsUnless you have restrictions about how your data moves and where it is stored, or need to have a trusted computing base with no externally developed software, or have very strict requirements that no available service implements (unlikely), you are better off just using an open source solution or paying for a service.# Real costEven if you have to pay for a commercial service, in comparison, the TCO of developing a similar solution in-house is very large.When you create

This simplified view misses some critical points:- The product won't do things exactly the way you want. If you build it yourself, you get it the way that you wish it had been built.- You're investing in someone else's product. Everything you invest in training and customization is wasted if you have to move to something else. You no longer have to worry about tech support either.- You're locking yourself into someone else's product, and you're stuck if sud

Well, this is a very one-sided take. Imagine being a dev tasked with evaluating a product that makes you look redundant and also costs the company license fees in perpetuity. Whereas building a homegrown solution ensures that you keep your job, and get to look like a rockstar who saved the company money. Gee, I wonder which one the devs picked.

I'm in this position right now and I have to call BS.We create our internal tools because buying puts us in a terrible position. For example SAP would do what our internal tools do. However SAP would cost more than our yearly revenue to implement. It would require expensive experts to configure for use and it would lock us in.Instead we have built a system that is working very well in a little over a year. With one developer.Sometimes what's on the market is not a good fit.

You don't. Developers would rather spend two months building their own than spending a dollar on yours. No matter how awesome. I have been there.

I'm surprised that at that scale you are still not building some core functions internally.Though it makes sense, buy over build is almost always the best choice early stage. It's hard to slow down product velocity to fix things that work fine when costs start to add up. (Also it's easy to say "do you want to save 3k a month or deliver features x,y, and z" and let costs slide)

Totally agree.Some engineers love to say "I can build this over a weekend". But the main cost is almost always on the maintenance side.I forgot where I saw this number - in the entire lifecycle of a piece of software, (on average) maintenance cost is at least 8x of the initial dev cost.Yes, buying a solution also costs time (and $$$) to integrate and maintain, e.g., using a 3rd party API - time to write code, time to set up monitoring / alerting, error handling... There a

The work that goes into "external code" is higher quality than most companies can achieve. The cost of developing a similar tool may also be outside what the company can afford to invest.If your business is online schema changes, then inventing it yourself makes sense. Otherwise you are likely throwing money away to create an inferior product.

When you have more money than time, prefer buying. When you have more time than money, prefer rolling your own. It's a well-known principle.For a VC-backed startup with millions galore and a pressure to beat competition, buying is natural.For a bootstrapped company or a side project, building your own may be best, especially when the advanced features that make market-leading solutions more expensive does not add a lot of value at the company's current scale, and the growth is no