Ask HN: At what stage did your company move from 3rd party to internal software?

5 points by geeky4qwerty 2 years ago | 12 comments

I work in senior IT leadership for a rapidly growing company (100MM -> 2B through M&A) and I'm curious about the experiences of different companies when it comes to the decision-making process behind developing internal tools versus relying on 3rd party apps/SaaS providers. There seems to be a pivotal moment for many businesses where the scales tip in favor of custom development, but I imagine this varies widely based on industry, company size, growth phase, and specific business needs.

When we had 500 users, a simple SaaS solution for $5 a user made sense, now that we're at almost 6000 it seems ludicrous for us to be spending $15k a month (after the 50% 'enterprise' discount) for software that that could be internally developed and maintained for a fraction of that cost over the products lifecycle.

codingdave 2 years ago |

"Build vs. Buy" was the term around this question way back when. And the answer landed fairly solidly on "Build your core value and unique business processes. Buy everything else."

Because that $15K for 6000 users is not about the cost to build the app. It is about saving the cost of internal staff to maintain the app. Even if you end up with 10 apps at $15K, the cost of the internal IT talent to maintain it is probably still more expensive, unless you find the miracle employee who can be a one-man wrecking crew for 10 different solutions, including the DevOps and other functions to support reliable operations and business continuity for all the apps. (24 x 7, too.)

I'd say that even if you do have an internal IT dev staff who could take it on... don't. Their efforts are better spent on things that are unique to your business, not re-inventing wheels.

withinboredom 2 years ago | |

Most "things that are unique to your business" are pretty straightforward and boring (the value is in the execution, marketing, and branding). It's all the other stuff that makes it an interesting place to work.

In other words, eventually, your talented engineers are going to leave to work on another company's "unique" things. Why not retain that talent and keep the business knowledge by having them build that other company's "unique" thing in-house?

The company I worked at had thousands of engineers and would build in-house vs. paying for it. Engineers stayed for well over half a decade because you could just volunteer to build something we were paying for (or switch teams to something interesting) instead of quitting.

muzani 2 years ago | | |

I thought it's the opposite. Most of the things we could buy are pretty boring - stuff like Slack, wikis, HR tools, CRMs, customer loyalty, travel claims management. I wouldn't sign up for a fashion marketplace job only to end up making a HR tool for it.

But I wonder if it's a front end vs back end thing, because front end are the peeps who also work on branding, marketing, etc.

bruce511 2 years ago | | |

It's interesting (to me) that you see half a decade as "keeping" engineers. I've been working at the same place for 30, the other developers for over 20. Clearly we're insane :)

Also, you phrase "keeping them" as if that's the key goal. Having developers stay longer working on projects for longer, leveraging domain expertise, building relationships, getting a deeper understanding of the system and its architecture are all good. Merely keeping them though serves no purpose.

Frankly, if an outside tool is sufficient then use it. Once the spend on that tool exceeds 2x a salary then -consider- moving I in house. (15k a month is getting there.)

BUT factor in commitment costs. You can hire a guy to build it, but you're committing to that post "forever". You've now got one more thing to look after,one more emp to manage, one more non-core project consuming resources. Do this a few times, and, well....

It's a fine line. There are benefits to moving it in-house, but the costs are not trivial.

withinboredom 2 years ago |

When it costs less to spend a years worth of salary building it vs. paying for it.

At a company, we would stick a team of up to 3 devs + manager on an internal product to replace or create something we wanted but didn't want to pay for. That cost is R&D (so taxed differently -- ammortized) so it would often be magnitudes in less cost than paying for a product, unless the product did something we conceivably couldn't build or only a small number of users would be using (such as on-premises BI tools).

lulznews 2 years ago |

Fraction of the cost? Really? That’s less than a single junior dev fully loaded. Laughable you would even consider this at $2B revenue.

geeky4qwerty 2 years ago | |

Not sure if you read the last part:

"...internally developed and maintained for a fraction of that cost over the products lifecycle."

Now, imagining a lifecycle of this specific app in question of 5 years, are you suggesting that a total spend of $900k for the SaaS would be LESS than developing and maintaining this one tool internally?