I own a Screenshot API service (shameless plug: https://getscreenshot.rasterwise.com/ https://getscreenshot.rasterwise.com/) and this exactly the argument that

I own a Screenshot API service (shameless plug: https://getscreenshot.rasterwise.com/ https://getscreenshot.rasterwise.com/) and this exactly the argument that I make for small utilitarian services like mine. You shouldn't build them because buying them is several orders of magnitude cheaper. I have a small paragraph from a blog post where I explain this with some math that is probably crappy but captures the idea: "When you spend time in areas that are not the core of your product, you're actually being financially inefficient. Taking screenshots is likely not a core task of your business so it doesn't makes much sense to waste development resources in this area. Here is a brief example of how inefficient it gets: A mid-level developer in a small market earns $90K USD per year, working 40 hours per week. His/her effective hourly rate is $47 USD per hour. Writing a basic implementation of a screenshot utility will take at least 5 hours. But this is just a simple prototype. Many use cases will need to be addressed, and there's likely going to be a large amount of time spent in optimizing, securing, provisioning, testing, etc. A realistic utility that can be used for a development workflow is going to take at the very least 30 hours of development time, but likely more. Other un-accounted areas of development time are: documentation, training and maintenance. Given this scenario is very likely that writing a semi-good solution will take more than a week and maintaining it, will take at least an hour every month. This means that writing this solution will cost almost $2000 USD of development time plus another $500 USD or so, just to support it every year. And of course, this doesn't include the cost of the infrastructure you're paying to run it." My argument is that the more utilitarian the service, the more cost-effective that is to buy it instead of writing it. Writing it could be simple but there's a drain in engineering resources when you try to maintain it in the long run.