This is a hard one, depends of many factors: what is the piece of technology you're trying to build or buy, time to market constraints, the quality of the off the shelf solution, company support, long term strategy and of course budgets.
There are things I would definitely "buy" or use like a web framework or a crypto library or those building blocks. Same thing, for example, for a imaging service, there's no point in building your own unless it's the actual core business (but even then, you could go the Heroku way and build layers upon layers to provide added value)
But sometimes is faster to build something in house or you have to do it because you inherit legacy code that you know could be better if only you could replace it with that library that everyone uses but there's no time or money to do it...
The cost of adopting "external" technology instead of building your own is the lock in in some cases (but who's going to write an alternative to Google BigQuery eh? :D) and in other cases the cost is just too high to justify the vendor solution: not all software is 10$ per month.
Another aspect of the build vs buy is the updates and maintenance. In house software requires maintenance but external one requires to be updated and monitored for security fixes and feature upgrades which can be a cost in itself.
I wonder what will happen if we all go the serverless route (which for a lot of use cases may very well be the ideal solution).
The cost of adopting "external" technology instead of building your own is the lock in in some cases
Whenever possible, and key to the whole discussion, it's important to build our own interfaces so that we can change between build vs buy if it comes to it. If you're decoupling things wherever possible then we don't have to make the perfect choice before we have all the info.
Today I might want to "buy" my "product recommender", but tomorrow I might want to build it. As long as I build with the mindset that I could swap out the internals for something else, I'm going to be safe.
I did something similar a couple of years ago. We had to switch from Parse to another provider for push notifications because they were closing shop so I did something like that, in case we had some issues with the new provider (Azure) and indeed those troubles came. The final switch to AWS SNS was definitely easier :-)
I think building a good interface makes it easier to choose, perhaps, the fastest/cheapest option now, while opening up for the more solid option later.
Being good about having good patterns for interfaces within your app doesn't seem so much a "cost" as much as a good "habit" to be disciplined enough to undertake.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is a hard one, depends of many factors: what is the piece of technology you're trying to build or buy, time to market constraints, the quality of the off the shelf solution, company support, long term strategy and of course budgets.
There are things I would definitely "buy" or use like a web framework or a crypto library or those building blocks. Same thing, for example, for a imaging service, there's no point in building your own unless it's the actual core business (but even then, you could go the Heroku way and build layers upon layers to provide added value)
But sometimes is faster to build something in house or you have to do it because you inherit legacy code that you know could be better if only you could replace it with that library that everyone uses but there's no time or money to do it...
The cost of adopting "external" technology instead of building your own is the lock in in some cases (but who's going to write an alternative to Google BigQuery eh? :D) and in other cases the cost is just too high to justify the vendor solution: not all software is 10$ per month.
Another aspect of the build vs buy is the updates and maintenance. In house software requires maintenance but external one requires to be updated and monitored for security fixes and feature upgrades which can be a cost in itself.
I wonder what will happen if we all go the serverless route (which for a lot of use cases may very well be the ideal solution).
Yes, you pointed out well, updates and maintenance is another aspect we should be looking at:)
Whenever possible, and key to the whole discussion, it's important to build our own interfaces so that we can change between build vs buy if it comes to it. If you're decoupling things wherever possible then we don't have to make the perfect choice before we have all the info.
Today I might want to "buy" my "product recommender", but tomorrow I might want to build it. As long as I build with the mindset that I could swap out the internals for something else, I'm going to be safe.
Decent software design for the win :-)
I did something similar a couple of years ago. We had to switch from Parse to another provider for push notifications because they were closing shop so I did something like that, in case we had some issues with the new provider (Azure) and indeed those troubles came. The final switch to AWS SNS was definitely easier :-)
But are you considering the cost and effort involved?
I think building a good interface makes it easier to choose, perhaps, the fastest/cheapest option now, while opening up for the more solid option later.
Being good about having good patterns for interfaces within your app doesn't seem so much a "cost" as much as a good "habit" to be disciplined enough to undertake.