“If it’s a core business function — do it yourself, no matter what.”
— Joel Spolsky, In Defense of Not-Invented-Here Syndrome: https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-...
— Joel Spolsky, In Defense of Not-Invented-Here Syndrome: https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-...
However, even more annoying is working at a Never-Invented-Here organization. I've been at a place which hired brilliant people, but then didn't let them innovate on pretty much anything. Write a simple TCP listener in Python to read a stream of data and then reply to it? That's crazy talk! We need to write a full Django app and deploy it behind Nginx behind a load balancer so that we can pretend it's highly available!
Don't get me wrong: the off the shelf approach is usually the right thing, but sometimes it just adds complication where it didn't need to be. It's insulting to be told you were hired for your expertise, but then not be allowed to actually use it.
This has infected my company quite a bit. People get really nervous as soon as you write something that’s little novel. Writing everything from scratch is bad but you also need room for people to innovate.
I’ve found this to be common in places with lower engineering skills. The “engineers” are mortally afraid of building anything novel for fear of failure; the COTS approach can get many clever folks pretty far in their career.
I think you also need to evaluate if it can even be done better than everyone else, and the effort required to do so.
Joel's quote is more narrow, which is a subset of the dangers of being completely reliant on someone else for your business.
Unless you've spent the last 10+ years working on encryption full time, please don't try it yourself.
I used to think I could write crypto. Then I learned more and realized it needs specialized knowledge I don't have the time to acquire. Then I spent some time trying to acquire it and figured I was OK to try again. Then I watched many other more experienced organizations crash and burn. My current position is that I know enough about crypto to know I never want anything to do with authoring it.
And if it is core functionality, you should have staff qualified to roll their own, and you should all know why you are doing this (i.e. what differentiation you are going after). This really isn't limited to encryption, it's just a hard domain that bumps up against a lot of other domains, so you see more failures than some others.
Basically if you are going to build a startup or new program in a hard domain, you need to have the resources to do it properly, and you need to know what those are before you start. This is where being a team of smart and motivated individuals may just not be enough.
Look at Intercom: now it's a juggernaut, but it started as an API mashup with a UI in front of it. If you can hit the market and start getting revenue faster you should. Many services have pay as you go and/or startup discounts.
That's your launch platform, then you start working from there.