[eitally]

And this is precisely why many large enterprises build things in house rather than license commercial tools. It's a lot more palatable to buy 3-5 full time developers to build and support and internal helpdesk than license ServiceNow, etc, for tens of thousands of users.

[vv]

There are risks to building in house too: Things will break over time Key programmer leaves, no good documentation or succession plan left behind New needs will arise (e.g. if you built an expense tracking app before smartphones, you'll now need to build a iPhone/Android app) Maintaining security - is your security team really better than the outsourced service's? API support Developer ecosystem

There's always a build vs. buy decision and sometimes you should build, but this is why even huge companies use Salesforce over maintaining an internal CRM.

[_delirium]

There's also considerable risk-aversion at large enterprises. Getting themselves into a position of significant dependence on a SaaS provider can be unappealing for at least two reasons, even if the pricing works for them initially: 1. risk that the pricing gets raised significantly, or the business's employee/customer profile changes in a way that raises the price to them significantly; or 2. risk that the SaaS provider goes out of business, is acquired, pivots, or otherwise significantly changes the service.

Building something in-house probably doesn't usually result in a better product up front (and definitely not for less up-front expenditure), but it can reduce some risks and be less constraining to future moves if you own the app.

[berkay]

It doesn't work that way in practice. I've been to more than one enterprise where an in-house developed application was no longer maintained, original developers were not available, and no one knew how the application even worked. There are very high risks in in-house developed applications, particularly if they are not vital for the enterprise (harder to have resources to maintain/enhance). Risk of SaaS provider going out of business or raising prices is no higher than traditional on-premise enterprise vendors (one can argue it's a lot lower). In short, there are risks in all approaches and they need to be managed. Good application architecture help manage those risks regardless of which route is chosen.

[eitally]

I disagree completely. Another benefit of traditional on-prem vendors is that it's a lot easier to get source code escrow written into the contract as a force majeur or bankruptcy contingency.

I was going to reply this to a different guy, but in my experience the risks of the in-house app going out of maintenance due to dev attrition or whatever are far lower than most people think. Stuff that's business critical is almost always staffed appropriately, and stuff that people perceive as business critical but actually isn't is usually the [large group of small apps] that aren't well supported. The big problem is the rinky dink Excel macros, VBA/COM+ add-ins, and random isolate single developer crap that nobody knows about except the end users.