Hacker News Reader

Comment by dsr_ | Hacker News Reader

What's the exit strategy for customers?

The biggest problem for a potential customer of a new service like this is that there is a high probability that the service won't be around in two years. The cost of the service itself is almost irrelevant: the cost of switching to something else can be very high, especially if the customer has more than a dozen users.

That's why XMPP is so attractive, even though there aren't many features built on it: you can run your own server, on metal or a VM platform, you can buy service with a guarantee that someone can take it over smoothly if one business model fails.

View on HN

hey dsr_, Silhouette and sitkack,

I'm Felix, the CEO of ChatGrape.

That's a big pain point we also had with a lot of services. Not necessarily when they were gone, but simply when we decided to try something new, which is part of the SaaS-Game imho. We are currently working on a convenient XML-Export that allows you to easily extract your Users, public discussions, etc. (no private conversations tho) at any time. To make the switch between ChatGrape and other providers easier, we'll have an option to export the data as Hipchat-XMLs, as they are already widely supported by almost every service.

Expect this to be out within the next two months.

Cheers, F

My main complaint is that services such as yours are not extending XMPP! By god, it's begging for it! Imagine if every e-mail service was a walled garden. Differentiate on features and user experience and otherwise embrace interoperability and you'll be better than the vast majority of chat startups out there.

I feel your pain, undata.

I think the biggest reason for many modern chat services to disregard XMPP is, because they fear that most advanced users might resort to their Adiums & Pidgins and wont use their web-services or Apps at all, resulting in half of the customers not experiencing the UX or unique features and therefore the value.

We had a long discussion in the beginning of the project and decided to make our architecture XMPP-friendly, but release it later in the future, as we need our early adopters to use the system.

So the answer to XMPP is "Yes, but after we gathered enough feedback"

most advanced users might resort to their Adiums & Pidgins and wont use their web-services or Apps at all

Oh, noes, that would be terrible. I cannot explain in words how much I loathe the Slack app and by extension how much I loathe their "UX experience and unique features."

Since my company just recently left HipChat for Slack, I think the odds of switching again this year are pretty slim, so I haven't evaluated your app. I just want to ensure that you have considered that a non-trivial portion of the engineering group of a company may want to resort to their Adiums.

I use slack, and I think it's pretty cool. Can you tell me what I'm missing out?

I think some of it is "worse than what": we were on HipChat, and it was not very nice, but at least they made an actual OS X application and allowed one to customize its behavior on my machine. The Slack "app" is just a packaged version of WebKit and has almost zero customizations. Worse of which is that there isn't a per-channel setting to hide images by default, since I've had no luck getting folks to stop posting animated gifs into the general channel. I'm not at work right now in order to speak to the specifics, but the Slack app doesn't handle that situation correctly at all.

And the notification is merely a red dot. Oh, you only want the red dot if you're at-mentioned or someone posts in your team's channel? Too bad.

If you just distribute your site's webpage as an app, you're phoning it in. And that is why I want a chat company to use XMPP so that I can use Adium to manage my interaction (or lack of it) with the chat service.

I'm glad you like Slack. I'm sure they're going to do well, given how many folks sing their praises.

The problem is these custom apps and web services are usually pretty poor compared to things like pidgin.

For some of us if it's not FOSS it's not going to be used.

I get that you want to showcase your features, but speaking for myself at least, choosing not to support XMPP means you don't even make the list of possible alternatives to what we have now. Making that promise is nice (if we can agree to call that a promise), but I have to make a decision based on what you provide now, not what you promise to provide in the future.

I think your UX and other unique features should be so compelling that customers want to use your system (over than Adium or Pidgin).

Think GMail for example. It's got full IMAP and POP3 support, and people who want to use a mail client are free to do so. If they do (and I assume many people do), then Google doesn't get to serve ads to them. But Google still gives you the freedom to choose. And they've succeeded in alluring even the nerdiest of people to their web app.

In short, let your users decide. Make your UI so awesome that they want to use it. Having XMPP support will actually draw many customers to your service, since it's something that not all competing services offer.

Hi winter_blue,

You and others made some very compelling points in regards of XMPP.

We learned a lot from this discussion and I'll soon write a post about the takeaways we got from this HN-Thread at our blog - http://blog.chatgrape.com/.

Thank you for your sophisticated feedback.

-f

It is much easier to differentiate a service if you don't need to take other clients that are out of your control into account.

One of the most time consuming things you can do is to diagnose, fix or work around issues in other applications that you don't control or even have source code access.

What's the exit strategy for customers?

I might not choose those exact words, but IMHO the fundamental issue this raises is something any SaaS company ought to be addressing in a transparent and up-front way these days if they want any credibility. Unfortunately, there aren't many who do yet.

Looks like chatgrape is positioning for a Goog acquisition, I don't think I would use a service this important w/o owning the software. Or at least an escrow.

Can you point to any SaaS best practices in this area? One example I read was that Everpix sold IP to finance the development of tools for data archive/export, before winding down. It would be instructive to survey wind-down scenarios.

Can you point to any SaaS best practices in this area?

That's surprisingly difficult. IMNSHO, most SaaS fails completely on this count, and my businesses use very few of the trendy services for exactly this reason. Of those we do use, every single one is either (a) convenient but expendable without compromising the business, or (b) both well established and having some form of legally binding statements along the lines below.

What I would ideally like to see in most cases would be a guarantee that if a service were to be taken down then its source code would be released with some form of open licence so that any service you relied on could reasonably easily be converted to self-hosting. Obviously this isn't worth much for services that are essentially proxies, such as most payment services, but it's sufficient for continuity in many cases.

Otherwise, as a minimum I'd like to see automated tools for exporting data in some open format so it can be transferred to an alternative platform where this is a reasonable possibility. Where there are non-trivial issues relating to data export, such as with PCI DSS for the various card payment services, I think the most plausible approximation would be a legally binding promise to help transfer the data to an alternative provider.

Obviously if a start-up fails suddenly then even legally actionable promises aren't going to be worth much if anything, which is why we won't rely on any SaaS from a new start-up for anything essential no matter what their terms say. However, properly worded guarantees would at least stop exit strategies like acqui-hire or sell-to-competitor-who-shuts-you-down from screwing the customer base.

One good example IMHO is MailChimp, which provides a straightforward mechanism for customers to back up all their important data, not just mailing lists but also things like e-mail templates and stats that normally live on the remote system.

Another one that seems reasonable is Stripe, which has explicit wording in its (UK) legal terms guaranteeing meaningful notice under fair conditions if they're going to terminate an account, and guaranteeing that they will facilitate transfer of card data to another payment service also under reasonable conditions if a merchant using their service decides to terminate.

Thanks for the detailed response.

Reply on news.ycombinator.com