8 ms·

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 i

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.

victor9000 6y ago
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.
- dnautics 6y ago
  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.
- jeromenerf 6y ago
  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".
- JMTQp8lwXL 6y ago
  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.
- aeternum 6y ago
  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.
q3k 6y ago
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.
themodelplumber 6y ago
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.)
- marmaduke 6y ago
  > 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.
- lexicality 6y ago
  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.
  - yawnxyz 6y ago
    or in Notion's case, a complete lack of documentation...
NoOneNew 6y ago
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!"
blackoil 6y ago
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.
gentleman11 6y ago
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.
- gfxgirl 6y ago
  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.
- CyberDildonics 6y ago
  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.
mauriziocalo 6y ago
+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 https://retool.com) than it is to even get started with SaaS vendors.
- lumberjack24 6y ago
  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 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 https://www.appsmith.com // Open source alternative to retool - https://www.internal.io https://www.internal.io // A no-code alternative to all the above - https://www.basedash.com https://www.basedash.com // Very spreadsheet like XP, YC20 startup
pc86 6y ago
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.
- corytheboyd 6y ago
  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
  - ethbr0 6y ago
    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.
    - 6y ago
pjc50 6y ago
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.
Scarbutt 6y ago
Many in the "serverless" all crowd are blind to this.
signal11 6y ago
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.
- beckingz 6y ago
  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.

victor9000 6y ago

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.

dnautics 6y ago
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.
jeromenerf 6y ago
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".
JMTQp8lwXL 6y ago
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.
aeternum 6y ago
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.

q3k 6y ago

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.

themodelplumber 6y ago

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

marmaduke 6y ago
> 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.
lexicality 6y ago
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.
- yawnxyz 6y ago
  or in Notion's case, a complete lack of documentation...

NoOneNew 6y ago

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!"

blackoil 6y ago

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.

gentleman11 6y ago

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.

gfxgirl 6y ago
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.
CyberDildonics 6y ago
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.

mauriziocalo 6y ago

+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 https://retool.com) than it is to even get started with SaaS vendors.

lumberjack24 6y ago
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 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 https://www.appsmith.com // Open source alternative to retool - https://www.internal.io https://www.internal.io // A no-code alternative to all the above - https://www.basedash.com https://www.basedash.com // Very spreadsheet like XP, YC20 startup

pc86 6y ago

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.

corytheboyd 6y ago
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
- ethbr0 6y ago
  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.
  - 6y ago

pjc50 6y ago

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.

Scarbutt 6y ago

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

signal11 6y ago

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.

beckingz 6y ago
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.