Hacker News Reader

Comment by cortesoft | Hacker News Reader

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.

View on HN

We recently purchased an enterprise scheduling software that I will not name (you may have heard of it, but it's unlikely). Told numerous times throughout the sales cycle by their architects and engineers that their API could do all the things we needed "easily" and that they could finish off the last few features we needed within 2-3 minor releases.

Fast forward almost a year, at least 7 releases, and probably $200k of payroll on our end and their product barely runs, and doesn't handle all of our standard workflow, let alone edge cases. Best we can assume is they were writing the API from scratch because we needed it and didn't have the skill to do so. Documentation was offensively bad when it was correct, which most of the time it was not, to the point where there were several instances of the endpoints in the docs being wrong, causing us to call support to ask what the real endpoints were we were supposed to be calling.

All this to say yeah, buying is great if the company is professional and has a well-documented product, and the sales and technical pre-sales folks know what they're talking about. But that isn't necessarily the case, even for six-figure purchases. And when it's not the case you can easily burn a non-trivial amount of money before you ever realize it.

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 otherwise? Haha not sure, just do as much research as you can but you’ll probably get burned anyway from time to time

> assume sales is lying to you until proven otherwise

Having dealt with enterprise sales countless times, yes they do and I yes I do presume so.

They lie in many ways, the most innocent one is by demoing unrealistic perfect scenarios without any corner cases, promising integrations that do not exist ("it's in the roadmap!") etc.

This is so standard it doesn't even deserve mentioning.

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.

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

I worked for a FAANG where this was part of my job. I would often come into rooms and question why the client was spending money on a product that didn't appear to suit their needs.

This was incredibly effective, as it meant that the client actually trusted us when we said something would work.

That being said, I'd normally avoid calling our products crap (even when they were) and just push the client to use something that wasn't crap.

This only worked though, because we had a separate reporting line to sales, so any VP pressure had to go through our VP (which happened, but not as often as you'd think).

My understanding is that they changed this after I left, with predictable consequences.

That’s the problem, isn’t it: Sales is a short-term metric (quarterly?), whereas client retention is long-term (multi-year, depending on contract length).

I had the pleasure of carpooling with some random owner of a small tech firm, and he flat out said it was difficult to keep on top of salespersons.

Meaning they were pretty shifty by nature and hard to trust.

One of the worst times I had as a developer was when my direct supervisor was a salesperson, who put me on a project that she had sold, and she was also the PM on the project. I thought I was going to die.

You had to work lots of overtime to deliver impossible promises already made to sell the thing?

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.

There's negative incentive for the selling company to do this. Too much of a risk that your prospective customer's engineers are just there for inspiration.

This is why pilots exist.

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

Well, this is what conferences are for.

+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 < 1 hour) to build a production-ready app on Retool (https://retool.com) than it is to even get started with SaaS vendors.

For CRUD internal tools, I'd still consider taking a look at other software vendors in the space. Everyone is moving so fast really.

- https://www.forestadmin.com // Fastest way to build self-hosted admin panels on top of SQL (Postgres, MySQL...) and Mongo databases

- https://www.appsmith.com // Open source alternative to retool

- https://www.internal.io // A no-code alternative to all the above

- https://www.basedash.com // Very spreadsheet like XP, YC20 startup

True. At that, one thing about the buying vs building argument that's missing is picking and choosing your battles. Competitive advantage comes from that. Build what you are capable of producing effectively based on your environment. Obviously you can run into roadblocks, but part of being an adult is planning and adjusting based on your circumstances and needs, not along someone else's. Too many of these arguments fall into the realm of, "Everyone, listen up! I have the single solution for everyone's problem for all of eternity!"

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

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

> I think it's enough to love the energy you can get from building something

I think this is good if you can get there. The IKEA of software is pure dopamine. If had to grow and saw those trees less so. If you are pouring concrete and get it delivered, pure dopamine. If you have to crush the aggregate by hand, less so.

Ah yes, this is how SAP and Oracle make their money: you "buy" a "COTS" solution, and then spend ten times as much having them build something for you .. which in the end you don't own.

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.

unity (and maybe unreal) have a real problem in that the majority of users are hobbyists, students, and new programmers. None of them are really willing to pay much for 3rd party code and they need $$$$$$$$$$$$$ of support because they are new.

For example make a JSON serialization library and you'll be asked "how do I spawn enemies from JSON" which is arguably entirely orthogonal to your library but don't answer and get downvoted for bad support. Do answer and you'll just be asked more questions about how to adapt your example to their personal project and you'll have to teach them programming in the process.

These incentives make it almost impossible to make money selling 3rd party code (plugins/add-ons). If you charge what it should really cost given the amount of work put in the market won't bare it. If you charge what the market will bare you'll go broke.

Maybe Unity should split the market into "Pro" and "Hobbyist" and the Pro market would have prices more inline with what it actually costs. Check out the prices of libraries like Radgametools.com (you'll have to google the prices) for comparison.

Unity also changes their APIs around with every tiny version increment, meaning that any app store package has to be constantly on top of installing new versions of unity and updating all the little parts that break every week.

That's very true. Especially for tooling/products/services that sells themselves as shrinkwrapped products that only allow for a particular flow - sometimes reimplementing your own subset from scratch that's geared towards your usecase is less effort in the long run than hacking around a blackbox solution.

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.

Precisely. There is a cost to integrating off the shelf software which people often forget. Less so in small startups, but in large enterprises this is non-trivial.

I've heard that large companies don't mind SaaS because they used to budget 30% or more of a software purchase's sticker price on annual support and maintenance.

That is why likes of Office 365 are popular, each component individually may not be best, but you get dozens of apps that are active in one go, for most parts are integrated well and have a simple billing.

Many in the "serverless" all crowd are blind to this.

While I agree with this comment, if someone buys and ends up in the position you describe then they did a poor job at buying.

there may be no options. For example, I (profitably) ran a small cloud. My supervisor kept questioning me "why don't we just use openstack instead of your software"? The answer is even in this article!

> Most enterprise systems require an engineering team to keep them running.

If we wanted a team of 3+ to run the cloud then we could buy openstack, or cloudstack, probably 2+, but that's also without pushing features. And suddenly we wouldn't be profitable anymore. I left, so I guess they will find out.

The people that have to perform the technical integration between two independently developed products (and could warn that the integration work is more involved than starting from scratch) are a different group from who decides the acquisition is happening.

Nowadays you're often buying SaaS so not only do you need to ensure the product is a fit currently but you must predict the fit going into the future.

It's not an easy thing to do. I've found that open source libraries are often more stable, require less ongoing maintenance due to API changes and have better support lifetimes compared to the SaaS equivalent.

Not always a poor job, but sometimes a bet that turns out wrong. I have seen great products and companies disappear in unforeseen mergers or API prices skyrocketing for instance.

Risk is low for commodities, but high for anything "disruptive".

Reply on news.ycombinator.com