[jaysonelliot]

This looks awesome. But our company probably won't use it. And here's why.

Committing to a new process or software is an investment of time and trust. When we choose something to use in our group, we want to know it's going to be there in a year or two, and still doing the thing we bought it for.

Software you can purchase and install on your own servers / desktops does that. In fact, we'll choose one software package over another if it doesn't force us to submit to updates until we want them, or rely on someone else's servers to stay functional.

Browser-based tools from someone else can make it into our workflow, but only after they've been around long enough and achieved mainstream adoption, so we can be relatively sure they're unlikely to "pivot" or disappear. Google Docs and Slack are good examples of this.

When you're new and unproven, there are already a lot of hurdles to leap in order to get users, especially business users.

Making your software user-installable eliminates a huge hurdle, I would recommend it.

[someonedan]

Hi Jaysonelliot, thanks for the terrific comment. It's really helpful for us to get this kind of insight.

Onboarding your team to any software is a risk. Our focus on being the easiest and most engaging task manager is aimed at being the least risky. We want to remove as many of those hurdles for business users as we can through simplicity and making team members feel more interconnected.

It's easy to say Google was also once "new and unproven", but Mahn's response below is an excellent one. I guess the issue is epeople want tools they can trust which here is "only after they've been around long enough and achieved mainstream adoption". But then, Slack was launched in August 2013 with 0 users. By June 2015 they had 1M+ users and a valuation of $2.76bn. (Source: WSJ). So new entrants to this market like us can establish themselves quickly but they need to be very good at what they do and they need to earn trust.

We aim to do just that and as jipiboily points out elsewhere, a payment solution is the first step to sustainability, which we've been developing with our research partners and will be rolled out at the end of the month.

[jaysonelliot]

For us, the preferable solution is to let us pay for it and install it ourselves.

For every Slack or Google that reaches mainstream adoption, there are a hundred smaller, often amazing companies, who don't.

Rather than rolling the dice on an all-or-nothing SAAS strategy that requires a big hit to get people to feel comfortable committing a whole organization, you can sell something people can buy, install, and own.

It doesn't mean you can't offer the freemium hosted option. What it does do is give you a chance to see organic growth in the early days. With subscription-based support services, you can even book more revenue — just the kind of thing a startup needs when they're looking for traction in the bootstrapped / angel funded days.

[Mahn]

Chicken and egg problem, from the point of view of the end user it makes sense and I would have the same reaction, but then I think to myself, shouldn't we give a chance for a "Show HN" product/service to turn into a Slack or Dropbox? How do they get there otherwise? We'll never have new shiny things if we are skeptical by defaut.

[jaysonelliot]

That's why I advocate for selling software in addition to offering it as a freemium hosted platform. It's a lot easier to make the decision to use something you own than to commit an entire organization to a hosted solution that may not exist in a couple years, or may change to the point that it's no longer useful.

[jipiboily]

That, or even just have an actual way to start paying now, which would already help to survive or make it feel like it would survive.