Was checking the numbers. Thought some of you might find it interesting. This doesn’t include the human factor, though now that’s kinda dialed back a bit as we move to HelpSpot work this year and Snappy is mostly feature complete (more to do, yes yes I know some of you are customers!). I’ve also probably missed a service or two, but nothing that major (I don’t think).
It’s profitable in the sense of covering it’s expenses well, though still a long way to go to recoup our costs. Hate the SaaS 
I’ve also probably missed a service or two, but nothing that major (I don’t think).
If I were to do the same on mine I would include business insurance, bank service / credit card fees, telephone charges, accounting / bookkeeping, domain registrations, SSL certs… Just some ideas 
Some of these might not be harder to separate out for you since you have multiple products.
Right, this is really just what it costs to run the actual tech services. I consider pretty much all of that stuff to be under HelpSpot’s domain. I also did ignore one off things like domains and SSL certs.
It’s not entirely fair to put things like the accountants and insurance under Snappy as if we were only Snappy we’d be running things very differently since we’d have almost no money (compared with HelpSpot)
If you use an accounting package like Quickbooks, they should have something similar to chart of accounts and if you filter by the expense category, it should give all your main expenses. If you decide to dump all your expense accounts here, you may do it for the income accounts as well for our benefit 
(just kidding)
Right, we can’t do that because our expenses are for the entire company and wouldn’t make any sense for just Snappy since the majority of our revenue and expenses relate to HelpSpot (non-saas).
@ian How does it scale with the # of customers? Like if you get more customers, the resources doesn’t cost that much more over time but you incur more costs on the other side such as having more CS agents and so on.
Would it be safe to say the longer you keep the customers, the more sustainable it becomes? The only thing I keep thinking is that if your service retains more data and requires more resources as the customers keep using your product, the costs would be unsustainable over time. However data and bandwidth costs are decreasing every year, does it scale with your resources?
As you can tell, I don’t run a business. 
For the scale of company Snappy works with resources shouldn’t be too big an issue. The current amounts already reflect us having a lot more server power than we actually need currently.
Humm… so you have two diffferent unrelated products in the helpdesk market? Care to share how or why you made that decision? I’m genuinely curious.
I think I have elsewhere, but the short version is Snappy sells to small co’s, HelpSpot while also sometimes used by small co’s tends to be more medium and up. Like one company that sells both SUV’s and cars.
If this is a good idea or not is still up in the air
I can’t speak for Ian and his team as to their intentions but I do think it is actually wise to create your own “competing product”, to learn from both products and take advantage of the best features from both. It’s what Google is doing by creating two versions of everything and you might find this article about what they’re doing more interesting.
For Snappy, I find it to be a young hipster version of HelpSpot, it feels like Ian and his team wants to do something radical with the new interface and modern features and see what works. Sometimes, doing the same thing on an older product may do more harm than being helpful because if you have long term customers, they may not be able to transition rapidly and most may not have the patience to go through severe changes in a short period of time where a young startup might.
Basically with a separate new product, you can go crazy without affecting everything else. You can quickly Iterate to add new features and see whatever works out. If it works, it can go into the more mature product and if not, either find a better solution in the younger product or kill it.