Live data from Hacker News

How we’re spending $55,930.08 a year on SaaS products

blog.sawhorsemedia.com

51–60 of 63 posts

Re: How we’re spending $55,930.08 a year on SaaS products

#51
post #26
post #23

Earlier quoted context omitted.

Paying someone to micromanage the services to get cost savings would cost at least $60,000 a year and make the company lose focus. There's no way digging into the details of the Mailchimp spend structure, for instance, is worth the time.

> There's no way digging into the details of the Mailchimp spend structure, for instance, is worth the time. Actually that's one point where you are not correct. For a good email campaign, it's imperative that you manage your list. You need to be looking at stats from the previous campaigns and making changes for future campaigns. If you have a lot of low-engaged/no-engaged emails, you need to try to re-engage them a…

Very few of these services can easily be replaced. You mention OpenFire XMPP - it has very few of the features that Flowdock has and is more of an effort to set up for end-users (compared with downloading an app or logging in on a website). You'd end up at most paying slightly less for a bunch of services with fewer features, at great disruption to your business.

Re: How we’re spending $55,930.08 a year on SaaS products

#52
post #43

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…

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

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

Re: How we’re spending $55,930.08 a year on SaaS products

#53

Interesting. Cheaper than the salary for an employee and probably together are able to help you do more than a single person.

> Cheaper than the salary for an employee...

True, but I wonder how much of an employee's time it takes to manage dealing with all these suppliers, technology integration time with each of them, and changing how these services are used each time a supplier changes its product offering.

Re: How we’re spending $55,930.08 a year on SaaS products

#54
post #4

Earlier quoted context omitted.

Since we run two products (both Muck Rack and the Shorty Awards), we end up paying twice for some services like Github.

I don't understand why you would host your source code externally? You can buy Atlassian Stash, once, for $1800/25 users, and use it forever: https://www.atlassian.com/software/stash/pricing

Github is really attractive with all the services that integrate into it. A service at $100/mo isn't much when you consider any labor time it saves ($50-$150/hour generally)

Re: How we’re spending $55,930.08 a year on SaaS products

#55

Earlier quoted context omitted.

I don't understand why you would host your source code externally? You can buy Atlassian Stash, once, for $1800/25 users, and use it forever: https://www.atlassian.com/software/stash/pricing

Github is really attractive with all the services that integrate into it. A service at $100/mo isn't much when you consider any labor time it saves ($50-$150/hour generally)

... and Stash is really attractive with all the local plugins that integrate with it, and allow you to do things that are really hard when you're stuck with web hooks.

Local installations don't cost hours-a-month to run.

Re: How we’re spending $55,930.08 a year on SaaS products

#56
post #25
post #21

There's a lot of unnecessary costs listed. For example, they spend $165.00 on dropbox for the team, but also use Gmail services (meaning they have Google accounts which come with a free 10GB of storage). The tier of MailChimp they use implies their list is in excess of 110,000 subscribers, and since I do a lot of email marketing for my company, I can guess their open rate is probably somewhere in the 10-20% range, so…

For many companies, the chat is critical. Also, if one person has to fix the chat for 1 hour a month, you are easily paying more for that person then for the external service. I would question that hosting in-house would be cheaper. As stated in other threads: that's less then the cost of an employee qualified to run all those services.

I set up OpenFire ~7 years ago for our company, and I think I've spent less than two hours on maintaining it in that time.

Re: How we’re spending $55,930.08 a year on SaaS products

#57
post #48

Earlier quoted context omitted.

Yeah, another problem stemming from this is that in many cases the user would need to grant you full account access. Still, Mint is a good example of a product that was able to gain enough trust from users that it had full access to all bank accounts, so maybe such a requirement is not an inhibiting issue. Any good product would need to be backed by a solid team with trustworthy backgrounds, though. This likely would…

If the service just provided "add a user, remove a user (hired, fired) and adjust billing appropriately", it would already be worth a lot and wouldn't need full account access. Its mind-boggling how many accounts I still have for companies I don't work for anymore.

Yeah, that would work, but the issue is that if you want to support "every" SaaS company, you need to solve the problem of integrating an SaaS product that does not offer granular permissions. e.g. An "admin" account that could grant/revoke access to users might necessarily also have access to sensitive company data.

In fact, it's the sensitive data that is the issue that will generate the most resistance from potential customers. Companies probably care way less about trusting you with their credit cards than they do with trusting you with sensitive vertical-specific data. THEN AGAIN, people are putting their entire company communication into Slack so who really knows...

Re: How we’re spending $55,930.08 a year on SaaS products

#58
post #29

Earlier quoted context omitted.

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.

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 prov…

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.

Re: How we’re spending $55,930.08 a year on SaaS products

#59
post #46

It's worth pointing out that, according to their team page [0], Sawhorse Media has zero dedicated backend engineers (apart from maybe their CTO). So, in their case, the alternative would be to hire someone just to manage these things (sysadmin, engineer, or whatever). In this case, I can see why they would make the choice of outsourcing everything. But if you already have an in-house engineering team who is reasonabl…

Agreed. Even when you have an in-house team, there are always other things that are core to your business to do. Growing a team is hard and expensive beyond the cost of the additional engineer. These SaaS tools let startups stay smaller, and that's priceless.

Re: How we’re spending $55,930.08 a year on SaaS products

#60
post #43

Earlier quoted context omitted.

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

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

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.

Post reply on HN