If this means I can remove my firefox CSS that hides the horizontal tab bar at the top, and instead have it hidden automatically whenever I have Sidebery open, then this is an advance
> AccessOwl calculates billing based on the number of active Slack users, excluding Single-Channel Guests and service accounts, as this is usually the closest measure to your number of active employees. The billing amount is updated prorata each month and before each payment, based on the number of users in your Slack workspace.
This severely limits the usefulness of a product like this.
Core aspects of the product like workflows and task management should not be tied to a chat vendor in my opinion, and would make me extremely nervous as a potential buyer due to your complete dependence on what SF does with Slack.
I’ve also worked places that strongly dislike Slack and won’t touch it since it was acquired by Salesforce. Ironically, your product would cause Shadow IT deployments (of Slack) in such environments.
Sharing these concerns because I think the product is a really useful concept, but your roadmap for these core functions would mean the difference between considering and completely passing over AccessOwl, i.e. for some subset of potential customers, the hard dependency on Slack is a complete blocker.
Depending on the point of view it can also be a strength. Actually many of our customers like that we're in Slack because their people are already there:
- no login required to request an access
- they don't need to "learn a new application"
So for end users that's great. There is still a web app for admins with more details.
But I can see where you're coming from. We plan to offer an alternative to Slack to be independent if the customers want that.
It sounds like you may have found your niche with existing Slack customers and if that works for you that’s great.
I don’t agree that this is a “strength”, because it limits the growth potential of the product while coupling critical functions to the whims of a 3rd party vendor. I absolutely do see how it’s beneficial for you in this early stage because it allows you to deliver a straight-forward experience for this particular user base (Slack customers) without building your own UIs. But that position of strength is fundamentally limited to that specific group. Move beyond it, and not only would using the product now require the adoption of a non-standard chat tool, but the core function of your product is completely orthogonal to chat making the Slack requirement also appear really odd. That group won’t have muscle memory for Slack or know all of its key features. That group will not benefit from any of the familiarity your current customers find compelling.
And back when I was a Slack customer (I actually like Slack and prefer it to the alternatives) I’d still be raising concerns because of the tight coupling with Slack features.
Not trying to just criticize your decisions here, but trying to elaborate on an outsider’s perspective as someone who has been in the position to bring this kind of product on board at large companies, and as someone who has dealt with the pitfalls of building products that have 3rd party integrations.
Best of luck to you on all of this and it’s good to hear there’s an alternative on the roadmap.
Learned about this on HN a few months ago. Less than 20 minutes to set it up with a cheapo USB KVM switch and it works great. I have a Model M keyboard plugged into a PS/2-USB adapter and the switches don't even confuse the keyboard.
