21–30 of 227 posts
All of this is true, but sometimes people forget that buying a solution doesn't mean there will be no work. Sometimes, the integration and maintenance of that integration ends up being more than building and maintaining your own solution, especially if you have to do any large changes to how your systems work in order to integrate.
All of this is true, but sometimes people forget that buying a solution doesn't mean there will be no work. Sometimes, the integration and maintenance of that integration ends up being more than building and maintaining your own solution, especially if you have to do any large changes to how your systems work in order to integrate.
I'd much rather occasionally work on feature for a well-engineered internal reimplementation than constantly fight with shellscripts wrapping around a solution with a huge impedance mismatch.
All of this is true, but sometimes people forget that buying a solution doesn't mean there will be no work. Sometimes, the integration and maintenance of that integration ends up being more than building and maintaining your own solution, especially if you have to do any large changes to how your systems work in order to integrate.
Plus maybe I'm weird but I think it's enough to love the energy you can get from building something. It's fun. And considerable portions of work should be fun. Especially if you work for yourself, where building stuff for money, for other people, often isn't enough without a strong connection between the work, customer, and the subject's own interests and values system.
(IMO a lot of those kinds of projects also build on the edge of one's core expertise, extending it outwards, almost like a recon mission, so it's less of a binary yes/no core expertise condition.)
1. Buy some platform/framework which you will then need to hire a small army of costly consultants to integrate and customize for your particular business need. Or
2. "Build" your own solution by orchestrating a bunch of open source technologies to solve your problem.
Moreover, it is not quite clear up front whether 1 or 2 will be costlier in terms of development effort and overhead.
1 There is some other expense you can save significantly on by DIY. An example would be DIY k8s on bare metal via bare metal providers for a massively bandwidth intensive service where paying AWS or GCP outbound data rates would be thousands and thousands a month.
2 You are at sufficient scale that there is an economy of scale that can be accessed. This overlaps a bit with the first point but can also happen if you are just big enough. The first point is more about some special need.
I own a Screenshot API service (shameless plug: 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…
Earlier quoted context omitted.
> their close cousins (Airtable, Notion) great as well! Their close cousins are locked, proprietary, slow, bloated, exceedingly complex, poorly designed (ui/ux), emojized, vc-backed feature extravaganza and have a subscription fee. Experts of Excel use keyboard exclusively, their keystrokes are a melody of efficiency, expressivity and productivity that is continued to be mocked in similar fashion as the 2007-era Mac…
I found Notion to be fairly simple to get started. Whereas when I opened Airtable my head exploded and I closed it immediately and haven't revisited it since.
All of this is true, but sometimes people forget that buying a solution doesn't mean there will be no work. Sometimes, the integration and maintenance of that integration ends up being more than building and maintaining your own solution, especially if you have to do any large changes to how your systems work in order to integrate.