Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Buy Don't Build

jrott.com

Post reply on HN
Print view View original

71–80 of 227 posts

Re: Buy Don't Build

#71

Post by dvtrn »

thinkharderdev wrote: post #25

These sorts of discussion always seem somewhat confused to me because "buying" vs "building" is not a binary choice. It is more often a choice between: 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.…

It would seem to me there are still two choices to make, meaning it’s still a binary choice-merely with more caveats and words involved to describe the options?

Re: Buy Don't Build

#72

Post by lexicality »

FpUser wrote: post #67
lexicality wrote: post #14

One of the few things I appreciate from my abusive first boss was making me acutely aware of the value of my own time. He was incredibly stingy with money and always wanted to know how much it would cost him to have his engineering team implement something vs how much it would cost to buy it and integrate it. Admittedly he was pathologic about this to the point of having us create a timer that counted in pounds sterl…

I think you had great boss (assuming he did not start timer each time you stopped typing on keyboard). Those endless meetings become unproductive pretty fast. I suspect that in big part they become a self sustained cancer used to justify time and salaries of unproductive company members. As for the subject itself: frankly I do not see any advantage of hosting on say Azure over hosting myself. Either requires a good d…

> frankly I do not see any advantage of hosting on say Azure over hosting myself.

In my opinion, cloud hosting only makes sense if your systems are architectured around being hosted on the cloud.

If you can build your application in such a way that it runs in the free tier of serverless, then it's going to be considerably more cost effective than renting a dedicated server - but if you can't, then it absolutely won't be.

Re: Buy Don't Build

#74

Post by ianmcgowan »

whoisjuan wrote: post #10

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…

As an aside, love your Lincoln, Hamilton, Jackson pricing plan, super creative!

Re: Buy Don't Build

#75

Post by gentleman11 »

cortesoft wrote: post #4

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.

In unreal and unity, most of the third party code I’ve tried to use ended up unusable because of either bugs, performance issues, or limitations. There are great exceptions but it’s been frustrating overall. The ones that do work, well, the documentation is often terrible and it takes longer to learn and integrate than it would to make your own. Finally, unity has a history of retroactively changing their terms of service to squeeze more money out of you for asset store buys, so it’s scary to trust them. I write a lot more of my own systems now.

Re: Buy Don't Build

#76

Post by taylodl »

Systems of Differentiation should employ a build-first strategy. These are the systems that differentiate you from your competitors, they are your competitive edge. As such you typically need tight control over these systems and don't want to rely on 3rd parties - either vendors or contractors.

Systems of Engagement & Systems of Record should employ a buy-first strategy. These are typically more operations-focused systems and as such you're usually better off buying them, but not always (see below). It's possible that some of these systems may also be Systems of Differentiation.

What is a buy-first strategy? It means consider buying first. How much would your operations be impacted by the necessary changes to your workflow? How much customization will be required in order for it to be usable and how are those customizations maintained throughout product upgrades? How much integration is required with existing systems? Buying software is rarely a buy, deploy, and done proposition! Usually the TCO is lower if you buy, but not always - depending on how much customization and integration is required.

Re: Buy Don't Build

#77

Post by bdcravens »

The hardest part of learning to not look through your developer eyes. Often the 80% solution is "good enough" for your customers or your stake holders, and they'd never appreciate the extra 20% a fully custom solution provides.

Re: Buy Don't Build

#78

Post by localhost8000 »

thinkharderdev wrote: post #25

These sorts of discussion always seem somewhat confused to me because "buying" vs "building" is not a binary choice. It is more often a choice between: 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.…

I understand your general point of there being a continuum of paying for building blocks to be integrated. But,

> is not a binary choice

Then, offering two options. :)

Re: Buy Don't Build

#79

Post by bdcravens »

thinkharderdev wrote: post #25

These sorts of discussion always seem somewhat confused to me because "buying" vs "building" is not a binary choice. It is more often a choice between: 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.…

Sometimes though we are dishonest about #1, and we want a deeper level of integration or polish than is necessary.

Re: Buy Don't Build

#80

Post by bdcravens »

taylodl wrote: post #76

Systems of Differentiation should employ a build-first strategy. These are the systems that differentiate you from your competitors, they are your competitive edge. As such you typically need tight control over these systems and don't want to rely on 3rd parties - either vendors or contractors. Systems of Engagement & Systems of Record should employ a buy-first strategy. These are typically more operations-focused sy…

The phrase AWS came up with for this, "Undifferentiated Heavy Lifting", is quite apt.
Post reply on HN