5 ms·

Just to flesh out the vendor comparison... Five weeks of, say, three engineers with $150k salaries ($200k fully loaded) is $60k. People say that the majority o

Just to flesh out the vendor comparison... Five weeks of, say, three engineers with $150k salaries ($200k fully loaded) is $60k. People say that the majority of software is after initial development. Let's say 20% is development [0]. That means this project costs $300k total and lives for 5 years before the team decides to rewrite it. That brings us to $60k / year. This is good savings! My general guidance to folks thinking about this sort of project is that you should implement a vendor and see how you like it. The reason being, MixPanel does a LOT more than this tool, and buying a vendor can help you figure out the subset of features that you actually need. Once you have a clear requirement list, you have a clearly scoped project and can hammer it out relatively easily to get that cost savings. Beware of thinking that you can do this for $X,000 / year on your own, or get it right on the first shot. There's a reason MixPanel (and any other vendor) has so many engineers. You're paying them to have already made the mistakes that you're about to make. [0] https://stackoverflow.com/questions/3477706/development-cost-versus-maintenance-cost https://stackoverflow.com/questions/3477706/development-cost...

ben_jones 9y ago
The whole thing is a big ball of mud. If you commit to a vendor you risk vendor-lock in. If you commit to hand-roll you risk runaway deadlines, feature creep, and a slew of other threats. Once you pick one or the other and get it to a business functional level you lose all momentum and willpower to pivot to the best solution now that you have a "good enough" approach.
- ProAm 9y ago
  Software is always 'Pay me now, or pay me later'. In the end I believe you usually always end up paying pretty close to the same, it just depends on if you are happy with the solution in 18-36 months or hate it.
  - bonesss 9y ago
    The tricky bit is when opportunity costs come in... "Pay me now" means sacrificing clear opportunities in the visible horizon, "pay me later" does the same thing at an less-controlled future point sacrificing presently unknown opportunities. Personally I much prefer 'pay me now', because 9 times out of 10, IME, some form of technical debt underlies the reasoning about why a team can't do something. 'It always pays to take the pain up front', basically.
- keerthiko 9y ago
  It's good to be conscious of vendor-lock-in as you implement a tool or library. If their product is good, at the worst you can borrow their API design and slowly reimplement portions of the back-end provided with your own implementations to liberate yourself. For a product/business that makes money, most often using a stable external tool is a better first-step. If things flip around again and you find a new library that solves your needs better than your homegrown lib, you can drop it in forking your lib and turning it into a wrapper on the external lib. At least this is what I have learned implementing high flexibility cross-platform mobile video playback solutions in our app over the last 5 years, where the landscape of libraries (and our own tools) has kept changing.
- erichurkman 9y ago
  Sometimes "good enough" is, well, good enough. How accurate good is good enough? 80%? 95%? It's different for every business, and the needs change over time. 60% accurate for an eagerly stage bootstrapped company? Gold! 60% accuracy on a growth-stage business where you should know what to do? Terrible. Be limber enough to eschew the tools that aren't working. But "good enough" is, well, good enough for most folks. Perfection the enemy of progress and all that.
deleted 9y ago
[deleted]
AFNobody 9y ago
> There's a reason MixPanel (and any other vendor) has so many engineers. You're paying them to have already made the mistakes that you're about to make. The real reason Mixpanel (et al) have so many engineers is: A) They need to scale their service to reliably provide to N corporations which is frequently non-trivial. B) They need to implement the 80% of features that aren't critical path for Company A because some subset of them are for Company B,C,D,E,F,G,H,I,J,K,etc. C) I've seen software vendors make some pretty terrible and painfully obvious mistakes. Idk, maybe I'm crazy but I have very little faith in this idea that more engineers = better decisions were made. I've just never found quantity has an impact on quality of the end product, only the speed at which its produced.
- dyeje 9y ago
  The number of engineers they have is irrelevant to the point. The point is you pay someone to worry about a specific thing so you don't have to and (hopefully) their expertise leads to a better product than you could have built.
  - AFNobody 9y ago
    > The number of engineers they have is irrelevant to the point. The point is you pay someone to worry about a specific thing so you don't have to and (hopefully) their expertise leads to a better product than you could have built. Yeah, and in my experience, that frequently fails to materialize which why I mentioned point C. Now, that could be arrogance on my part but it doesn't change my experience on the quality of the vast majority of outside software vendors.
a-saleh 9y ago
We went for a vendor to replace one of our internal tools. It looked too costly to pay team of 4 engineers a year to support it. Unfortunately, the part "implement a vendor and see how you like it" went only with the first half. Complaints of developers supposed to be using the tool were brushed aside as a simple resistance of change. In the end it was implemented by decree from higher management. Only after all the paperwork was signed, we started to see that the vendor doesnt support our usecases, that their hardware is underpowered for the load we were expecting, e.t.c ... In the end, I have heard at least 20 various senior and beyond senior engineers from various teams complaining that they spend 20 to 50 % of time working around the vendors bugs, around once a month bringing down vendors infrastructure, because our use-case mandated uploading more data than the infra could handle. I definitely agree that clear requirement list and clearly scoped project and implementing a vendor to see how you like it is usually better than in-house On the other hand in-house is usually better than implementing a random vendor because management feels like it ;)

ben_jones 9y ago

The whole thing is a big ball of mud. If you commit to a vendor you risk vendor-lock in. If you commit to hand-roll you risk runaway deadlines, feature creep, and a slew of other threats. Once you pick one or the other and get it to a business functional level you lose all momentum and willpower to pivot to the best solution now that you have a "good enough" approach.

ProAm 9y ago
Software is always 'Pay me now, or pay me later'. In the end I believe you usually always end up paying pretty close to the same, it just depends on if you are happy with the solution in 18-36 months or hate it.
- bonesss 9y ago
  The tricky bit is when opportunity costs come in... "Pay me now" means sacrificing clear opportunities in the visible horizon, "pay me later" does the same thing at an less-controlled future point sacrificing presently unknown opportunities. Personally I much prefer 'pay me now', because 9 times out of 10, IME, some form of technical debt underlies the reasoning about why a team can't do something. 'It always pays to take the pain up front', basically.
keerthiko 9y ago
It's good to be conscious of vendor-lock-in as you implement a tool or library. If their product is good, at the worst you can borrow their API design and slowly reimplement portions of the back-end provided with your own implementations to liberate yourself. For a product/business that makes money, most often using a stable external tool is a better first-step. If things flip around again and you find a new library that solves your needs better than your homegrown lib, you can drop it in forking your lib and turning it into a wrapper on the external lib. At least this is what I have learned implementing high flexibility cross-platform mobile video playback solutions in our app over the last 5 years, where the landscape of libraries (and our own tools) has kept changing.
erichurkman 9y ago
Sometimes "good enough" is, well, good enough. How accurate good is good enough? 80%? 95%? It's different for every business, and the needs change over time. 60% accurate for an eagerly stage bootstrapped company? Gold! 60% accuracy on a growth-stage business where you should know what to do? Terrible. Be limber enough to eschew the tools that aren't working. But "good enough" is, well, good enough for most folks. Perfection the enemy of progress and all that.

deleted 9y ago

[deleted]

AFNobody 9y ago

> There's a reason MixPanel (and any other vendor) has so many engineers. You're paying them to have already made the mistakes that you're about to make. The real reason Mixpanel (et al) have so many engineers is: A) They need to scale their service to reliably provide to N corporations which is frequently non-trivial. B) They need to implement the 80% of features that aren't critical path for Company A because some subset of them are for Company B,C,D,E,F,G,H,I,J,K,etc. C) I've seen software vendors make some pretty terrible and painfully obvious mistakes. Idk, maybe I'm crazy but I have very little faith in this idea that more engineers = better decisions were made. I've just never found quantity has an impact on quality of the end product, only the speed at which its produced.

dyeje 9y ago
The number of engineers they have is irrelevant to the point. The point is you pay someone to worry about a specific thing so you don't have to and (hopefully) their expertise leads to a better product than you could have built.
- AFNobody 9y ago
  > The number of engineers they have is irrelevant to the point. The point is you pay someone to worry about a specific thing so you don't have to and (hopefully) their expertise leads to a better product than you could have built. Yeah, and in my experience, that frequently fails to materialize which why I mentioned point C. Now, that could be arrogance on my part but it doesn't change my experience on the quality of the vast majority of outside software vendors.

a-saleh 9y ago

We went for a vendor to replace one of our internal tools. It looked too costly to pay team of 4 engineers a year to support it. Unfortunately, the part "implement a vendor and see how you like it" went only with the first half. Complaints of developers supposed to be using the tool were brushed aside as a simple resistance of change. In the end it was implemented by decree from higher management. Only after all the paperwork was signed, we started to see that the vendor doesnt support our usecases, that their hardware is underpowered for the load we were expecting, e.t.c ... In the end, I have heard at least 20 various senior and beyond senior engineers from various teams complaining that they spend 20 to 50 % of time working around the vendors bugs, around once a month bringing down vendors infrastructure, because our use-case mandated uploading more data than the infra could handle. I definitely agree that clear requirement list and clearly scoped project and implementing a vendor to see how you like it is usually better than in-house On the other hand in-house is usually better than implementing a random vendor because management feels like it ;)