Ask HN: At what stage did your company move from 3rd party to internal software?
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.
12 comments
[ 4.4 ms ] story [ 61.1 ms ] threadAt 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).
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.
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.
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.
> 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 :)
Sounds like a place I'd like to work in the next couple of years. I've been doing startups lately where keeping an engineer longer than 2 years is a challenge. I could dig some stability again.
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.
- data lake and supporting tools (we fired over 100 million analytics events in a single day).
- a/b testing software (assignment and analysis)
- support software
- email sending tech (we sent over a billion emails a month)
- hr tooling (the company hired in over 50 countries)
- payments integrations
- probably other stuff I don't remember
Basically, due to scale, these tools were interesting in their own right. Paying for them was either impossible (no off-the-shelf solution would be able to support it) or prohibitively expensive or both.
I do remember a cool thing that some foreign Huawei guys I worked with used to use. It would call a ride sharing service, pick the more cost effective one, and then handle the claims for that. Presumably it checks that the location is work/home and only applies for such conditions.
"...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?