[mmahemoff]

It's significant this is a SaaS company using these services. Some of the services have a cost based on team size, while others have a cost based on user base (and usage volume).

Services whose cost is f(team size): CircleCI, Trello, Github

Services whose cost is f(user base): MixPanel, Moz, Shopify

I mention this distinction because the f(team size) services generally offer solid value to any team, being useful and less expensive than paying someone to build the same thing in-house. OTOH the f(user base) products are a lot harder for consumer apps to justify than business apps. They do occasionally offer enterprisey premium features like platinum support, but the main pricing scheme is based on X whatever's per month, and a SaaS company charging lawyers $100/user/month is a lot more likely to afford it than a casual gaming website with a million users and a some ads.

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

[Argorak]

Github (SaaS) is not f(team size), it is f(projects). You can have as many users as you want and the price will stay the same, if you don't cross certain repository thresholds.

Github Enterprise is f(team size)

CircleCI is also f(usage), you can decide to have less capacity. (Although, in the case of CircleCI, more developers hopefully maps to more tests, so indirectly, it is f(team size))

[mmahemoff]

I realise some of those services aren't directly f(team size), but as a general rule of thumb, f(projects) is a proxy for f(team size).

Likewise, your CircleCI bill is going to be higher with more team members as you mention.

That's all very imprecise, it's not like there will be a direct linear relationship. But close enough compared to Mixpanel etc which scale with f(users) or f(transactions).

[Argorak]

That depends highly on your team. If I have 20 support people with access to GH, but no coding work, the cost factor is not the team size. On GH enterprise, that's another kind of math. There's certainly also projects that just run in one repos for ages (long live the monolith).

Also, with GH, I can always choose to take a project off GH and archive it. That wouldn't make sense if it were user-billed.