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