Re:Ask HN: Whats a Build vs. Buy decision that you got wrong?
by int0x2e on Thursday December 29, 2022 @03:42AM
(#34170750)
I suspect there's a hidden trap here due to survivorship bias - those of us who were lucky enough to see hugely successful products/services that got some of these decisions spot-on in the beginning, see how wonderful it can be when you are able to make these investments early on and build things once. The risk is that you fail to count the number of teams that did the same sort of analysis process and still made the wrong decision because they ended up pivoting, or just straight-up made the wrong call...
Replacing a managed solution in a small-scale product really isn't required, because it likely doesn't cost you enough. Replacing it in a high-scale product does matter, but that also mean you should be making enough money to make the replacement pay for itself. If you make the decision to use the managed solution and it's wrong, that's something you can usually fix. If you go DIY when you should have paid for it - you rarely get to correct it in time, and it might just be another nail in your coffin due to lower velocity, focus, etc...
I would counter with stack overflow which has scaled great over all this time on only a few self-hosted servers.
The trouble with replacing the buy with a diy later on is that it will now cost at least twice as much to build, because 1) you're maintaining the existing system which takes some of the people most familiar with the problems of the existing system, and 2) the existing system will still evolve a bit because that's business, so you're also trying to hit a moving target.
I think other posters have it correct, you have to think hard about how central a particular feature or service is to your business model. Chances are, differentiating yourself means off the shelf solutions won't be a perfect fit for your core revenue, but all other supporting services should probably be off the shelf.