151–160 of 227 posts
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.
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/…
A brutal experience.
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.
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 wrote a piece just a few days ago talking about the same topic, although it was aimed at earlier stage developers, so there is less detail, but the overall message is similar:
Deciding when to build a custom solution in web development
https://blog.markjgsmith.com/2020/12/11/deciding-when-to-bui...
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.
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.