Live data from Hacker News

Buy Don't Build

jrott.com

101–110 of 227 posts

Re: Buy Don't Build

#101
You can only buy stuff if you know that stuff is aligned with what you need.

Further, you need to consider that the stuff you buy also needs to aligned with your needs over time.

However, you also need to consider this when building stuff.

The alignment is the tricky thing it is easier to achieve when building in-house as long as you engineering is up to the job.

Also, note that building in-house doesn't mean engineering "from scratch". Usually it means use lower level components over higher level components/services.

Re: Buy Don't Build

#102
post #97

Some people take lifetimes, even multiple reincarnations to come to the conclusion that they are buyers, not sellers. Some people are born marketers and are very good at persuasion, hyperbole, and other tools to sell a product/service. Others are natural consumers: they develop tastes and grow to be rabid shoppers. It's good to sit in the middle of these two opposites, but often better to decide which extreme you wan…

I'm sure a lot of people would love to go all-in on the buy side. Where do you get the money to buy something if you don't sell anything though?

> Where do you get the money

In this case we assume there is a cashflow of some sort. How the cashflow comes into being is a public matter for most, but sometimes a private matter. It is assumed that a certain amount of disposable income can be used to acquire tastes and become a 'shopaholic' of sorts.

Re: Buy Don't Build

#103

Earlier quoted context omitted.

Exactly. I've even had this happen with things like CSS, where a master stylesheet changes somewhere upstream on another server, and hundreds of hours of my own custom, vendor-supported modifications now make my web application or website look like doo-doo. 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. Es…

My job involves a lot of integration work so I'm probably biased, but I find successfully cracking open a poorly documented API and extracting all the data in a usable way to be deeply satisfying, especially if you can be confident enough in your edge cases that you think it'll run until the next unannounced and undocumented change comes along.

or in Notion's case, a complete lack of documentation...

Re: Buy Don't Build

#104
The longer I run small businesses, the more sceptical I become of this sentiment. I wrote a cathartic rant here at first, about all the different ways external services have let down my businesses over a period of many years and how often our in-house systems have been the only thing that kept us going in those situations. But instead of letting rip and naming names in rather undignified fashion, I have decided to settle for just posting the conclusion.

I want to agree with the principle that you build what is essential to your business and you buy in the rest. As both an entrepreneur and a developer, I want to focus on the unique, value-adding parts of whatever my business is doing. I want to let someone else handle the mechanical stuff and the formalities, and I have no problem with paying a fair price for that.

But that whole argument is predicated on the idea that outsourcing will get an overall better result than building in-house, so that in some way it saves time and/or money that you can better invest elsewhere. So many services we've used have changed or discontinued functionality and forced us to relearn or reintegrate just to avoid going backwards, so many services we've used have pushed their prices up in real terms while adding little of extra value to us, so many services only ever reach 75% of what we'd like from them and the missing 25% of functionality hurts more and more, so many services we've used just don't work so often that you wonder how they manage to stay in business at all, that I now find it hard to trust or expect good results from any external service at all.

Sometimes you have no choice about outsourcing. No small business has the resources to do some things, particularly in heavily regulated areas like payments and tax, or in large-scale infrastructure like operating a data centre, unless that is part of the purpose of the business. So you choose the least of evils and hope for the best.

But today, as someone just starting to set up another business, I am looking for services that handle everything in a particular area where for practical reasons we can't do it in-house. I want to specify what we need, and have it done and the results delivered. I don't want to care about anything in between. I don't want to be distracted by any related legal and regulatory compliance matters. I just want the job done, properly and legally, for a reasonable price. I have little interest in working with anyone offering less than that, unless I have absolutely no choice.

Maybe this means I actually do agree with the original principle after all, and I've just learned from experience that an extreme interpretation of it is the way to go.

Re: Buy Don't Build

#105
It's interesting that the whole article is pitched around a context where there is a basic assumption that there is a whole engineering team, devops etc., and the question is about how their time is best utilized. But if you chose to buy instead of build everything most of that would not exist.

So there's a paradox I see which is akin to the credit system where only people who don't need credit are offered it: you can only "afford" to buy instead of build when you have the engineering competence to build - that's when you can intelligently choose not to.

On the other hand, if you lack the internal competence to build and for that reason choose to buy? That's when all the bad things happen. You're going to get screwed by your vendor - they are going to know you aren't technically capable of supporting yourself, they will give you stupid timelines, blown out costs, unreasonable constraints ("it has to have a 16 core, 256GB RAM server or we won't support it") etc etc. You will end up with the worst case of vendor lockin and a system everybody hates.

So one of the pitches I make when people are making this decision is that you should be building at least some things, because the strategic cost of not doing that affects everything else you do.

Re: Buy Don't Build

#107

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.

+1. And I'd add to that that sometimes there's significant work in the pre-buy phase as well:

- Researching what your options are / what's already out there.

- Comparing different alternatives.

- "Hopping on a call" with a sales rep to get a product demo (there's this super annoying trend where many SaaS companies' landing pages don't explain what they do and the only option they give is to "schedule a demo").

For CRUD-like internal tools or simple 3rd party integrations, my experience has been that it's often much faster (typically https://retool.com) than it is to even get started with SaaS vendors.

Re: Buy Don't Build

#108

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. :)

Haha, yes that it is a bit awkward

Re: Buy Don't Build

#109
post #71

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?

Yeah, that was phrased somewhat awkwardly. The binary choice I was rejecting was between

1. "Buying" a solution that solves your problem exactly and doesn't require engineering resources to implement and maintain

2. "Building" a solution where you have to solve every problem from scratch where you don't have any particular expertise.

Re: Buy Don't Build

#110

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.…

cost is often not clear up front, but neither is benefit!

this is where experience matters.

Post reply on HN