in Articles

An Update on Snappy

UPDATE: We’ve found a great new home for Snappy and we won’t be closing. You can read the update here:


Effective today we’re won’t be allowing any new signups for Snappy. We’ll continue to run the service until May 15th, 2015 to give existing customers a chance to move to a new platform, perhaps our other help desk software app, HelpSpot.

The tl;dr Why

We don’t get a chance to do that many things, and everyone should be really excellent. Because this is our life. Life is brief, and then you die, you know? And we’ve all chosen to do this with our lives. So it better be damn good. It better be worth it.
—Steve Jobs

The Long Version

Just under three years ago we started building Snappy as a tool for small support teams. Our primary product is an enterprise help desk software app and I thought a small light SaaS app to go along with it would be a good fit. While HelpSpot is often used by very small teams, it has a lot of tools and features which an individual or small team doesn’t need. Wouldn’t it be great to build a tool just for them?

It would also be a chance to try some new things, experiment in ways that aren’t possible with an established existing application and explore a new UI paradigm.

We have an outstanding team at UserScape, and they put tremendous effort into the project. What we’ve created is a great application, but it’s not a great business.

To be even more specific, it’s not a great business for us. We’re a small team, and we already run a very profitable product in HelpSpot. Nearly three years in I expected Snappy to be able to contribute in a more significant way to UserScape’s revenues, but it’s just not there.

Part of this may be the long slow SaaS ramp of death, but even if that is the case we simply can’t continue to devote our limited time to Snappy. At some point, the tradeoff between adding even more great improvements to HelpSpot vs continuing to build up Snappy just doesn’t pay off.

The reality is that finding customers for Snappy for $30/month average sale is as time-consuming as finding ones for HelpSpot that go for thousands. It’s also just as competitive at the low end of the market where Snappy is vs the middle where HelpSpot is, but far less profitable.

For our business, the middle tier of help desk software apps is also just a better fit. They’re more enterprise oriented, and that’s an area where we just work a lot better.

We understand how to navigate the committee making the purchasing decision, how to deal with PO’s, how to walk customers through one on one demos. And, once those customers choose your product (for a much higher price) they stay for a very, very long time.

So, it’s not so much about Snappy as it is about us as a company. With five people you can only do so much. One of my biggest errors has been thinking we could do more than we can or should. That’s something I’m trying to rectify.

I feel terrible for the customers that have chosen Snappy as a solution. I know it’s not easy to pick a help desk app and that there’s often training and integration issues that make it a bigger commitment than other applications.

I hope providing this advanced notification will provide enough time for people to transition to HelpSpot or another solution. I’m happy to speak with customers who may need more time and make accommodations for them as we can.

I know people will have a variety of questions. I’ve kicked things off with a few below if you have more please comment below or ping me with them on twitter.

Q / A

Where do you think things first went wrong?

I’m 100% to blame 🙂 I let the scope creep from the original vision. The very first idea for Snappy was to make it extremely simple, essentially an engineering as marketing effort to lead people into HelpSpot.

Along the way I got excited about some of the new possibility building this from the ground up allowed. That was a huge error.

If it’s making some money and growing why close it?

There was an interesting post over on the Baremetrics blog about this. The first two elements there are very relevant to Snappy.

Essentially, Snappy has a very low average monthly revenue per user. Not as low as his example of $20, but not that far off. At those levels, you need a lot of customers to make the app worthwhile. And again, in our case when Snappy makes less in a month than HelpSpot makes in a day it’s hard to justify it after you’re already a few years in and the growth curve isn’t hockey stickish.

His second point in that post is also very relevant. Snappy has a pretty hard cap on how much it can earn off any single customer. Given it’s designed for small teams, medium/large teams are essentially blocked out.

We’ve had a few customers of large size, but the vast majority are 1-3 users. So again, at those levels you’re forced to find a huge number of them over a relatively short period to make the finances work.

Would you sell it?

We did reach out to a few people who I thought might be a good fit to take it over, but nothing panned out.

This type of app is mission critical; I’d be very nervous to put it in the wrong hands. It’s better to close it than to sell it to the wrong person.

So, I wouldn’t say it’s impossible that we’d sell it but it would have to happen pretty soon, and it’d need to be someone I really trust.

Why don’t you just let it run indefinitely and see how it goes?

This was my A plan for the past few months. However, it’s just too important an app to the businesses that use it to leave it like that. It’s also not a simple application to manage. There’s a lot of moving parts, email, servers, widgets, integrations, etc so “just running it” can be more complicated than it sounds.

While it overall has been an extremely stable and reliable application things can and will go wrong. It’s not fair to the customers to not be 100% on top of it.

Is UserScape in financial trouble?

Not at all! This is a business decision though there is of course a financial component. Primarily, it came down to if we want HelpSpot to continue to subsidize Snappy’s development costs. At this point I simply don’t think that’s the best use of those dollars.

Why was starting a second product a mistake?

While we do run some other side projects like LaraJobs, having a full on second product that requires continuous development was not a good idea for us at this stage.

I overestimated my energy to take on such a massive endeavor. I also thought as a company we could take on more and that wasn’t correct. In the end, it was too much of a distraction and financial undertaking for our small crew.

Will you open source Snappy?

I’ve kicked this idea around a bit. I think the problem as with most SaaS apps is that it’s very much tied into a variety of other services. It would be impossible to run Snappy without at least several hundred dollars in services a month outside of hosting.

I think it’s hard to open source an application like that. Also, simply dumping it in the GitHub open source bin without taking on the continued development and management of it doesn’t seem that useful to anyone.


  1. Oy Ian! It’s really great that you’re so transparent about the product and the company. I’m sure this was a tough decision, but it’s hard not to understand. Time is short, we only have so many productive years. We might as well spend them on projects that are add value for everyone involved!

    • Thanks Brian! Yep, super hard choice but it’s what’s best for UserScape as a whole. I’ve learned a ton as well, so definitely not a complete loss.

  2. Thanks for the run-down, Ian. Sad to see it go. Time to start making a transition plan.

    I wanted to press a little bit on the idea that you couldn’t let the app continue to run. Not for the purpose of “seeing how it goes” business-wise – as you’ve said it’s probably not a good market for you. But just for the purpose of supporting existing customers at break-even.

    I remember reading about how 37 signals handles sunsetting products and that seems like a totally manageable approach. Isn’t the vast of the majority of the cost in onboarding new customers and building new features and dealing with the bugs that arise from new features?

    For example I, as a user, asked a bunch of support questions early on when I was getting started. Now I don’t ask any at all.

    • Hey Kalen,

      Yep, that’s something I gave a TON of consideration to. There’s a few issues though. First, as I mention just having it around and not improving it, only fixing major bugs, etc isn’t really fair to the customers either. Second, Snappy has a relatively small customer base. 37sigs products that they’ve sunset A) Have huge install bases B) Are profitable to the tune of millions of dollars. So that makes a big difference.

      They’re also about a 10x larger company (probably more by revenue) than UserScape so they have ops guys to just keep the servers running all day for example. At our size to have me or one of the devs running servers on Sunday nights for a product that’s not making any money it’s not really sustainable long term.

      • Oh ya I mean if you’re having to spend time on a weekend actively supporting it, that’s hard to calculate the price of. I would have imagined it would be fairly stable server-wise by now though?

        I’d have to disagree with having it around without feature improvements being unfair to customers. The type of customer that doesn’t want to leave is exactly the type of customer who is okay with the current feature set. And if they’re worried about adding more features, they can leave at their leasure.

        • It is stable, but there’s always something. Just this last Sunday Linode force rebooted all the servers. So there could have been trouble with them coming back up, etc. A few weeks ago memcache died and we had to fix it up. If you have someone who’s job it is to always do that that’s fine, but at our size that constantly being over your head on a product that’s not making much money when those mental cycles could be used on your main product that makes a lot of money is a tough tradeoff.

          Sure, some customers will stay forever but there would be a steady decline through natural churn. Certainly, if we had the staff to just let that happen, to naturally petter out I likely would have gone that route but for who we are right now it’s not really feasible.

          • Gotcha – ya that kind of stuff is definitely a time and energy sync when you aren’t already having to deal with it. I forgot that you’re not really in the SaaS game outside of snappy (hate the saas!) – so that makes a bit more sense now that I think about it.

            But aren’t you getting into a hosted version of helpspot soon though? I thought I remember seeing that somewhere.

          • Yep, hosted HelpSpot is coming. That only adds to the stress though. Also, HelpSpot could afford a dedicated ops person or service. For example, HelpSpot has made more in sales today than Snappy has this year. It’s unfortunate, but that’s the math.

  3. Hey Ian, sorry to hear it! We’ll miss Snappy here at Dribbble – we came to it from Desk and the difference in our happiness and productivity doing support was immense. You guys were always incredibly responsive to bug reports and suggestions as well. We’ll miss having such a supportive relationship with our support tool 🙂

    Thanks for the thoughtful (as always) blog post on this subject as well. Interesting stuff and (from my vantage point) it sounds like you’re doing the right thing. Best of luck with HelpSpot and other future endeavors!

    • Thanks Rich. I’ll definitely miss working with you guys. I LOVE Dribbble, it’s always cool when one of your customers makes something you admire so greatly (I guess you probably get that feeling a lot running Dribbble!).

      HelpSpot might not be right for you guys, but if you take a look and it is let me know. Happy to help you try it out.

  4. Hi Ian,

    Sorry to hear that Snappy hasn’t worked out as you’d hoped, but I completely understand the rationale.

    You argument against open sourcing the application makes sense if you assume that people will want to actually run Snappy on their own servers.

    However, I think a lot of Laravel devs would really appreciate the chance to take a peek under the hood at how everything is organised. I certainly would.

    • Yeah, I do get that geek aspect to it 🙂

      It’s something I’ll kick around a bit more. It’s done in a very Laravel-ish way so not sure there would be a lot of surprises, but there are probably no OS Laravel apps as big and complicated as this so that would be interesting from an academic standpoint. I’ll think about that.

      • I’m also one of those who doesn’t care I can set it up and use it, but would really love to poke around and see how you have tackled different problems when you made it 😉

        Just throwing it out there with no guide or support would be enough for people like me who’s just interested in the code 🙂

  5. Sorry to hear it didn’t work out. But it sounds like you are doing the right thing in the circumstances.

    Ps/ “Success is 99% failure”!

Comments are closed.