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

[geeky4qwerty]

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]

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

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]

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.

[withinboredom]

Some of the things we built in-house because it wasn't worth buying at our scale:

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

[muzani]

Interesting. I wonder why most of these are being sold by startups and not the giants that use them regularly.

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.

[withinboredom]

Scale and custom stuff. It’s a lot easier to hardcode things than build stuff for the masses.

[HenryBemis]

It makes perfect sense to build when you are at a certain scale. I remember talking to Citi's C-suite some time ago and their mentality is/was "we are an IT company that is also a bank". But! you have to be Citi (or the likes of your company - perhaps you are in Citi? :) where you can get the talent, pay them handsomely, and keep them motivated.

[bruce511]

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]

That's my mistake; I wasn't trying to imply that. I was merely trying to say that once you have a set of tools in-house, keeping engineers is a side-benefit. Not that you should do it for the sake of keeping engineers.

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

[withinboredom]

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]

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]

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?