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

131–140 of 227 posts

Re: Buy Don't Build

#131

Post by corytheboyd »

ethbr0 wrote: post #127
corytheboyd wrote: post #124

Earlier quoted context omitted.

I have been in the boat of the company that ripped you off before. Sales will promise the world, product/engineering caves “just one last time” to help win the deal with the easiest shittiest thing. Years go by and things inexplicably break all the time. It’s such an easy trap to fall into, because I hear similar stories all the time. I guess the moral of the story is to assume sales is lying to you until proven othe…

Why don't more companies mandate that their engineers talk to the company's engineers, alone, in an unrecorded room, before agreeing to buy? I mean... talking to people with every incentive in the world to stretch the truth and/or little technical acumen doesn't sound like a recipe for success.

I’ve been on calls almost like this. What you get are solutions/sales engineers accompanied by sales. They’re all generally helpful, including the engineer to engineer conversations. I’ve even been in a position where a representative of a vendor worked directly with us for months, yet the same issues kept coming up ultimately leading to the project being scrapped. It’s a weird world where everyone is trying to sell something to everyone, I really don’t like it

Re: Buy Don't Build

#132

Post by ethbr0 »

JoeAltmaier wrote: post #128
ethbr0 wrote: post #127

Earlier quoted context omitted.

Why don't more companies mandate that their engineers talk to the company's engineers, alone, in an unrecorded room, before agreeing to buy? I mean... talking to people with every incentive in the world to stretch the truth and/or little technical acumen doesn't sound like a recipe for success.

You get in a room with Intel, you have to sign a waiver that gives Intel total property over everything discussed in that room. Even your own products, if you happen to mention something about them. No sensible company will let their Engineers in an Intel conference room, if they have any sense.

Granted! But it seems less of a case in the SaaS B2B horror stories that come up frequently.

I'm assuming Salesforce (e.g.) isn't going to suddenly pivot into Lyft-for-dogs, or whatever the product is.

Re: Buy Don't Build

#133

Post by ethbr0 »

pixl97 wrote: post #130
ethbr0 wrote: post #127

Earlier quoted context omitted.

Why don't more companies mandate that their engineers talk to the company's engineers, alone, in an unrecorded room, before agreeing to buy? I mean... talking to people with every incentive in the world to stretch the truth and/or little technical acumen doesn't sound like a recipe for success.

Because vendor companies have figured out you wine and dine the C level and pretend that engineers didn't exist. I'm pretty sure my company wouldn't put me on the front lines during sales for reasons like this Customer "How are you at X and Y" Me "Oh, our X is really good, on the other hand our Y is utter shite" Sales rep next to me: evaporates

Isn't that a win for everyone except the sales rep though?

If the deal closes, Z% of the company ends up being tied up in trying to kludge Y into doing what was sold, spiking engineer burnout and lowering morale, and furthering a negative relationship with sales.

Plus you've now pissed off your new customer, by lying to them.

Re: Buy Don't Build

#134

Post by nitrogen »

tixocloud wrote: post #119
simonw wrote: post #116

One thing to pay close attention to when making a build v.s. buy decision is the impact that billing models will have on your usage of a tool. Take logging for example. If you buy a log aggregation platform like Splunk Cloud or Loggly the pricing is likely based on the quantity of data you ingest per day. This can set up a weird incentive. If you are already close to the limit of your plan, you'll find that engineers…

Very interesting perspective. Ran into the same issues where Salesforce was charging us by the number of columns we had that ended up forcing the team to overload a column with a JSON object so we could get it to work without overpaying. Integration and maintenance turned out it be a downright nightmare. Would be interested to hear various pricing models to understand the pros/cons for each especially in the logging/…

For things that are directly generating revenue, it makes sense to have per-X pricing because it aligns your vendors' interests with your own. In that case, you want to incentivize the vendor to maximize your usage, because that usage is making you money.

Re: Buy Don't Build

#135

Post by gshulegaard »

simonw wrote: post #116

One thing to pay close attention to when making a build v.s. buy decision is the impact that billing models will have on your usage of a tool. Take logging for example. If you buy a log aggregation platform like Splunk Cloud or Loggly the pricing is likely based on the quantity of data you ingest per day. This can set up a weird incentive. If you are already close to the limit of your plan, you'll find that engineers…

I love this comment because it articulates a dynamic that I think is often overlooked much better than I could. I might even go a step farther and suggest that anything that is core to your business flywheel should be built and not bought (in general).

Mostly because you don't want pricing to act as a disincentive to exercising the flywheel.

Re: Buy Don't Build

#136

Post by rendall »

ethbr0 wrote: post #133
pixl97 wrote: post #130

Earlier quoted context omitted.

Because vendor companies have figured out you wine and dine the C level and pretend that engineers didn't exist. I'm pretty sure my company wouldn't put me on the front lines during sales for reasons like this Customer "How are you at X and Y" Me "Oh, our X is really good, on the other hand our Y is utter shite" Sales rep next to me: evaporates

Isn't that a win for everyone except the sales rep though? If the deal closes, Z% of the company ends up being tied up in trying to kludge Y into doing what was sold, spiking engineer burnout and lowering morale, and furthering a negative relationship with sales. Plus you've now pissed off your new customer, by lying to them.

Alas. Then the company doesn't get the contract, while the next company who lied, with a bright white smile, does.

Re: Buy Don't Build

#137

Post by ummonk »

The problem happens when Ops software tends to be GUI-based and overly complex, and you just want some programmatic / command line tool you can properly integrate into your software / processes.

It's often simpler to take open source software and adapt it to your needs than to buy commercial software.

Re: Buy Don't Build

#138

Post by ummonk »

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…

I think the screenshot service is a perfect example of a service suited for buy don't build - it's something complex to implement but with a really simple API to integrate with.

Re: Buy Don't Build

#139

Post by hootbootscoot »

Mmmm probably depends upon what it is. Core competencies of your business? Probably not the best thing to use an external service for. (Assuming your core competency is not cloud computing & storage) Your core will need to constantly be extended, honed, refined, redefined, poked at, prodded etc...
Post reply on HN