Launch HN: AccessOwl (YC S22) – Automating SaaS Provisioning and Permissioning
44 comments
You base your pitch on other companies' SSO Tax, but you have an Enterprise Tax just like them: We are an org with ~10 users and would like features from your Enterprise plan, and it doesn't even have pricing posted without meeting a sales rep. Even if we had 50 users, which isn't so far in the future, we wouldn't be an "Enterprise" but we'd still like to purchase your products.
Oh yeah, you're right we haven't seen it like this yet. Although the point about SSO Tax is that you need to have the highest Enterprise plan to get SSO functionality at every SaaS tool. We just sell more features (not SSO) in another plan.
But I see your point. We should split and reorganise our plans a little bit. What's the feature you're interested in Enterprise?
The main feature missing is automatic user provisioning (your version of SCIM?). Access review is nice and also not just for enterprises, as many businesses today need to be SOC 2 / ISO 27001 compliant, but since its a quarterly process it's less critical.
I agree with you. SOC/ISO27001 became more popular. Even quarterly access reviews are already pain the more people you have. Documenting all the things is a lot of work.
However, feel free to try our product or contact us to get a live demo :-)
We've been using AccessOwl since March (came across them via the Slack app store while searching for something to help with SOC 2).
My thoughts:
- The founding team seem to know what they're doing. I've put forward a number of feature requests / bug reports over the last 5 months and they've generally very responsive, often fixing bugs the same day
- They've added a number of larger feature requests over the last 5 months—one in particular being something to help with quarterly access reviews, which has helped to alleviate a real pain point we had
- Driving it from Slack seems to works pretty well for the team and people seem to be using it
- AccessOwl see themselves as a single source of truth for vendors, however, the reality is that it's the vendors themselves that are the source of truth. The accuracy of AccessOwl currently relies on the team using it 100% of the time.
- The design of the product is a little rough around the edges, however, as they seem on top of the product generally, I'm personally happy to work around that for the time being
- Most of the workflows work well enough. Offboarding users for example is better than what we had before.
- Onboarding a new team member is one area that currently falls short. You're able to setup templates to onboard people with, that contain a bunch of apps you want them to have access to, however, you're only ever able to select one template—in most cases for us, that means you can use a template to quickly onboard a new user with about 1/3 of the apps they need, but for the rest of them you're forced to do them one by one, and need to keep track of where you're at outside of the product—it's extremely slow and cumbersome and much worse than our previous method.
- On balance, they have got a promising product, and provided the new user onboarding issues were fixed, would generally recommend it
My thoughts:
- The founding team seem to know what they're doing. I've put forward a number of feature requests / bug reports over the last 5 months and they've generally very responsive, often fixing bugs the same day
- They've added a number of larger feature requests over the last 5 months—one in particular being something to help with quarterly access reviews, which has helped to alleviate a real pain point we had
- Driving it from Slack seems to works pretty well for the team and people seem to be using it
- AccessOwl see themselves as a single source of truth for vendors, however, the reality is that it's the vendors themselves that are the source of truth. The accuracy of AccessOwl currently relies on the team using it 100% of the time.
- The design of the product is a little rough around the edges, however, as they seem on top of the product generally, I'm personally happy to work around that for the time being
- Most of the workflows work well enough. Offboarding users for example is better than what we had before.
- Onboarding a new team member is one area that currently falls short. You're able to setup templates to onboard people with, that contain a bunch of apps you want them to have access to, however, you're only ever able to select one template—in most cases for us, that means you can use a template to quickly onboard a new user with about 1/3 of the apps they need, but for the rest of them you're forced to do them one by one, and need to keep track of where you're at outside of the product—it's extremely slow and cumbersome and much worse than our previous method.
- On balance, they have got a promising product, and provided the new user onboarding issues were fixed, would generally recommend it
Thanks for the kind words and your constant feedback!
Onboarding is definitely one of the topics we want to iron out further. As of right now we only support RBAC (role based access control), basically one role/template for one type of user. Our goal is to offer ABAC (attribute based access control) in the future where one user carries several attributes (country, team, management level...) and applications + permissions are being matched to those attributed accordingly.
Hope to have it live for you to test it out sooner than later!
Onboarding is definitely one of the topics we want to iron out further. As of right now we only support RBAC (role based access control), basically one role/template for one type of user. Our goal is to offer ABAC (attribute based access control) in the future where one user carries several attributes (country, team, management level...) and applications + permissions are being matched to those attributed accordingly.
Hope to have it live for you to test it out sooner than later!
Very relevant tool for this SOC2 compliant org. I have seen lot of general purpose automation tools pitch this but I think domain specific automation like this gives you much better value for money.
Absolutely. We are big believers in best-of-breed software, where you really do ONE good job instead of trying to do everything.
Just to add, There are bigger competitors in the space like Bettercloud and other. Going upmarket will be a problem for you guys because these companies have already acquired orgs that will have a larger ACV. Problem is real though. Also, when an org starts growing, a dedicated IT team is hired to manage these roles, entitlements, value stream, networking etc. That means, you have a small window when the org is not too small and not too big probably Series A to C (100-500 people org), implies the TAM might be small. Food for thought.
Indeed, we're aware of Bettercloud and others. But that's the point, they're focusing on the enterprise market.
When we worked in our startups before we couldn't use solutions like Bettercloud as they were just not affordable (especially when you need to upgrade all your tools to the highest plan) or didn't even talk to us when we don't bring them 100k per year.
We want to help startups and scaleups, basically focusing on the SMB market. These customers don't have good solutions as of now.
We want to help startups and scaleups, basically focusing on the SMB market. These customers don't have good solutions as of now.
It’s definitely a market that will have some interest. I have a company with 20 people that’s doubling year over year and could use something exactly like this.
You’ll have to convince me to trust you and that the product actually does what you say it does and that you’ll be around in a year.
But the thesis is sound I think.
You’ll have to convince me to trust you and that the product actually does what you say it does and that you’ll be around in a year.
But the thesis is sound I think.
Yes, I mean in the end the startups from today are the enterprises of tomorrow. And we can learn and build while growing with them.
I see your point about trust. That definitely takes time to build up. Companies like Zeplin already work with us. It would be amazing getting the opportunity to convince you too!
That's true, but lot of startups actually die before they become enterprises. That implies your churn might be high. You might be in a situation where you allocated support resources for an org that runs out of money.
Also, I think the pricing is very low. For $2.5 per user, for an org of 100 users, ACV is $3000, that implies for a 1M ARR, you need around ~340 SMBs, which I think is possible but it is on the higher side and it is lot of effort. You are pricing implies Bottoms up, But for adoption you need the whole org's buys in which I think does align at scale. Just to put things to perspective, smaller orgs (20-50) pays $5000-$6000 to drata, vanta and others for SOC2/Compliance.
Again from customer point view it is cheap and great but economics may not workout.
Just food for thought. I wish you success.
Also, I think the pricing is very low. For $2.5 per user, for an org of 100 users, ACV is $3000, that implies for a 1M ARR, you need around ~340 SMBs, which I think is possible but it is on the higher side and it is lot of effort. You are pricing implies Bottoms up, But for adoption you need the whole org's buys in which I think does align at scale. Just to put things to perspective, smaller orgs (20-50) pays $5000-$6000 to drata, vanta and others for SOC2/Compliance.
Again from customer point view it is cheap and great but economics may not workout.
Just food for thought. I wish you success.
Hello, this solves a real problem for me as a growing startup CTO (~70 people) still handling most account creation / removal manually. I couldn't find a list of your integrations on your website? Seems like it should be a top level menu entry!
Great to hear that this would solve a problem for you! Do you have somebody else helping you with account creation/removal or are you still doing it on your own?
I agree that we need to put more work into our website and list all integrations there. But I guess most of the applications you use, we're covering already.
I agree that we need to put more work into our website and list all integrations there. But I guess most of the applications you use, we're covering already.
> But I guess most of the applications you use, we're covering already.
That seems like an unnecessarily bold statement when your landing page mentions +100 integrations
That seems like an unnecessarily bold statement when your landing page mentions +100 integrations
I think the statement was meant to be softer
“But I’m guessing we cover most of the applications you’d use”
I’ve read a couple other comments from them, and am pretty sure it’s a minor fluency thing. I’d give them the benefit of doubt :)
“But I’m guessing we cover most of the applications you’d use”
I’ve read a couple other comments from them, and am pretty sure it’s a minor fluency thing. I’d give them the benefit of doubt :)
You have a point here, indeed. What I mean is that we cover the "typical" apps many tech companies use. But yes, not everything is integrated yet.
Congratulations on the launch. This is great - I had started to feel the pinch of provisioning de-provisioning 2-3 years ago and wrote scripts for ~10 SaaS applications. Worked great until we started to get more and more SaaS apps and there was a day when I spent more time writing script for the tool rather than for the actual product of our company. Ditched the tool the next day.
Was planning to open source the tool but didn't really get the time then - great to see you guys solving it well! Congratulations!!
Was planning to open source the tool but didn't really get the time then - great to see you guys solving it well! Congratulations!!
Thanks! We can really relate to that. Would love to hear more about what tools you did that for and what your experience were. Hit us up if you are open to chat!
That's very good and any ISO 270001 certified small-medium company would need that. But it would be better to have stand alone web interface and not only relay on Slack.
Organisations that don’t use Slack aside, driving this from Slack is a real benefit in my experience.
A system like this lives and dies on the team actually using it, and by allowing them to drive it from where they already are (Slack), we’ve found the team are actually using it and don’t have many complaints about the workflows either.
A system like this lives and dies on the team actually using it, and by allowing them to drive it from where they already are (Slack), we’ve found the team are actually using it and don’t have many complaints about the workflows either.
Funnily we started with a pure web interface. But after testing it with a bunch of orgs we quickly noticed that some people have issues finding the URL where to request accesses or when they found it to finally sign in.
So we came up with the idea of bringing it to Slack: Cool thing is that the user is already logged in and can just interact with AccessOwl. We can easily keep him up2date about his/her access request.
However, I agree we shouldn't solely rely on Slack as orgs without Slack just can't use us at the moment. That's a good point! We already provide an admin interface as web app for easier filtering, reporting etc.
However, I agree we shouldn't solely rely on Slack as orgs without Slack just can't use us at the moment. That's a good point! We already provide an admin interface as web app for easier filtering, reporting etc.
Do you plan to integrate with SSO providers or become one? This is cool, but seems like kind of a limited market because why would I want to maintain this information in two places (AccessOwl and my SSO provider).
Currently AccessOwl works well with "Sign in with Google". More to come.
We don't plan to be come an own SSO provider as we believe authentication is solved good enough. But setting the right permissions for a user account is not. So you SSO provider does not have information which permission somebody has only that somebody has access to an app. That's we do differently basically.
We don't plan to be come an own SSO provider as we believe authentication is solved good enough. But setting the right permissions for a user account is not. So you SSO provider does not have information which permission somebody has only that somebody has access to an app. That's we do differently basically.
When do you plan on implementing Office365 / Azure SSO?
I would ditch Okta tomorrow and throw money at you. One of the reasons I stay with Okta is their ability to automatically provision accounts with SaaS providers. It's not 100%, but it's more than 80% of the apps we use have integration with them and seem to provision/de-provision well.
I would ditch Okta tomorrow and throw money at you. One of the reasons I stay with Okta is their ability to automatically provision accounts with SaaS providers. It's not 100%, but it's more than 80% of the apps we use have integration with them and seem to provision/de-provision well.
In regards to de-provisioning we are not relying on a SSO provider. The SSO provider plays a bigger role for us when onboarding an organization to read out what applications have been used by whom.
Would love to understand your case better. Are you using Azure SSO and Okta SSO in parallel? Without knowing the specifics of your tool landscape I believe we can help you there. Here is my calendly in case you want to share more details: https://calendly.com/accessowl/30-minutes-pdt
Would love to understand your case better. Are you using Azure SSO and Okta SSO in parallel? Without knowing the specifics of your tool landscape I believe we can help you there. Here is my calendly in case you want to share more details: https://calendly.com/accessowl/30-minutes-pdt
Scheduled for next week - thanks!
IME people define roles and groups in Okta which then translate to how auto provisioning works. As you know, support for these features via SCIM varies wildly which is where y’all come in. That’s why I’m curious if you plan to integrate with Okta, because you fill in the gaps which seems really valuable and it’s a market segment that obviously isn’t a afraid to spend money on this problem. I’m not sure if other products like Rippling or JumpCloud already fill this gap though.
We currently have customers that are using Okta/Rippling but, as you say, wanted a solution with easier to use workflows and the support of non-SCIM provisioning.
We are definitely not shying away from working with existing solutions. We believe we can provide a great value even if you already use Okta/Rippling/Jumpcloud, as they typically focus on SCIM and therefore often only partially cover your SaaS tool stack.
We are definitely not shying away from working with existing solutions. We believe we can provide a great value even if you already use Okta/Rippling/Jumpcloud, as they typically focus on SCIM and therefore often only partially cover your SaaS tool stack.
Funny coincidence, the logo is very similar to a convenience store we have in Australia: https://nightowl.com.au/
Haha true. We realized after designing it ourselves that there are lots of owl logos out there!
We see owls everywhere since that, kinda cool :-)
I was just speaking to a customer yesterday and they have the problem that you are solving. I have forwarded the link to your post.
Amazing, thank you!
Are you hiring customer service agents or support engineers by any chance?
Unfortunately not at the moment. But this might come. Feel free to send something via https://www.accessowl.io/career and we'll reach out when this changes :-)
kevinmm(2)
Seeing how the founders do EVERYTHING to create value gives me absolute excitement
Most of us use SaaS tools for work day-in and day-out. How do we get access to those tools? For the most part, through a colleague or IT admin who creates all accounts and sets permissions manually.
Here’s what it usually looks like for the unfortunate admin: (1) receive a request for a new tool via email, Slack, JIRA or face-to-face. Since you are busy with something else, you write a todo for later; (2) you log in to the tool and realize that the permission that was requested is way too high so you check in with the requestor’s manager; (3) you finally set up the account and document user, tool and permission in a Gsheet/Notion/Airtable.
This quickly becomes a 30m task for a simple access request! This is still the best practice for most people and it sadly also was for us. We were both founders before and experienced the same tedious process in different flavors at our own startups and other companies.
At some point we migrated to Okta and partially automated our provisioning and deprovisioning (permissioning, however, stayed painfully manual). Why only partially automated? Because Okta utilizes the SCIM API which was either not available in our tool stack or required an expensive upgrade to enterprise-subscription (thanks to the “sso tax”: https://news.ycombinator.com/item?id=31175300). And yet, we still missed simple things such as approval steps, a straightforward way to request access, and access reviews.
We talked to hundreds of organizations and saw the same manual processes and self-built scripts everywhere. The pain often starts at growing companies with around 50 employees. At this stage the CTO usually gets fed up with manually (de)provisioning and documenting it in a Gsheet. Another widespread cause of headache are IT security certifications (e.g. SOC2, ISO27001,...), requiring to know which employee has access to what tool, regular access reviews, and timely offboardings.
It seemed crazy that in a world where SaaS has become the norm, there was no great way to manage something as seemingly “trivial”, but also as critical, as user accounts. The core issues are, as always, missing integrations. Despite SCIM being the standard for over a decade, not all applications are utilizing it. Worse, many vendors lock it up in their enterprise plan.
This brought us to our core design principle: AccessOwl has to work with every tool, no matter what integrations are available. We generalize all the available ways of integrations in a single, simple interface. We take care of all the grunt work needed to coax each SaaS tool into doing the right thing. Whether it’s calling public APIs or resorting to Plaid-style automations as a last resort. Our first iteration was a simple workflow in Slack (Request -> Approve -> Manual provision). It covered all access documentation and solved back-and-forth communication between stakeholders. Since then, we have been adding more and more integrations to SaaS tools to directly (de)provision without the use of SCIM APIs. Taking a similar approach to provisioning as “Plaid” did in banking. We’re already covering 100+ tools and counting.
So what does a typical workflow look like?!
Step 1: Request an access, onboarding or offboarding. For this we piggy-back on whatever messaging tool is used in your org (we are starting with Slack, Teams will follow). It’s as simple as clicking a button to get your request started (no more manual JIRA tickets!) and always gets forwarded to the right stakeholders.
Step 2: Provisioning and permissioning. In the most basic workflow the tool owner receives the approved request with all the information to manually provision the account. If and when you arrive at the point where manual provisioning becomes a pain, you can let us automate it for you. The requestor will automatically get process updates and the access will be audit-ready logged in the background.
Prices start at $2.5 per employee per month and we charge a fixed premium for the automation of (de)provisioning based on the total number of employees.
We are excited for the opportunity to share AccessOwl with you! We would be more than excited to hear your thoughts and feedback and your own experiences with SaaS access management!