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.<p>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.
"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."<p>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.)<p>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.
When it costs less to spend a years worth of salary building it vs. paying for it.<p>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).