6 ms·

I was heading tech and product of a SAAS software for ~15 months so writing this from that experience. - Who is the buyer? Typically they are not same as the u

I was heading tech and product of a SAAS software for ~15 months so writing this from that experience. - Who is the buyer? Typically they are not same as the user of the product so understand what they look for in similar products. - SSO, preferably SAML based. - As for security, take care of OWASP top-10 [1] and you should be covered for app-sec. - Implement RBAC. Make it easy to add/manage users for an admin-user. - Setup a demo account in sandbox, fill it with data as close to real world as possible. Makes it super easy during sale pitch. You let your product talk instead of you. - Consider multi-tenancy from right off the bat. It's hard to add it later. - Look up your domain specific compliance requirements and build those from ground up. Some such as SOC 2 don't hurt. While at it, get a decent security vendor to pen-test your product, work with them to fix high/medium priority issues and get them to issue certificate. It builds credibility with customers. - Reports. Typically the admins will require a bunch of reports. It's best to give them a CSV/Excel download and let them slice and dice in their spread sheet software. - Users will make mistakes so always use soft-delete. You can always do hard-delete after a few months. [1] https://owasp.org/Top10/ https://owasp.org/Top10/

mywacaday 4y ago
Some great points there. I would also add a way for business users or admins to easily review accounts and privileges and sign off on that review if you are targeting any kind of regulated industry.
- vishnugupta 4y ago
  +100. Look up maker-checker [1]. Almost all the enterprise systems require a human to review and approve changes initiated by someone else. Even if you don't implement it right away, be aware of it and if possible build your entity/data model such a way you can add it later without turning your architecture upside down. [1] https://en.wikipedia.org/wiki/Maker-checker https://en.wikipedia.org/wiki/Maker-checker
NetOpWibby 4y ago
This is excellent, thank you!
bradgessler 4y ago
https://www.enterpriseready.io/ https://www.enterpriseready.io/ is a good starting place that enumerates most of the great points made in the parent comment.
mooreds 4y ago
Disclosure: I work for an auth service vendor. Great feedback about knowing who the buyer is. Lots of folks think about the user, but knowing the buyer (and they are usually not the same person) is critical too. If you are a building a SaaS, I'd recommend outsourcing your auth, since that is both critical and undifferentiated functionality. There are lots of solutions out there. FusionAuth is one option (I work there); here's our multi-tenant guide: https://fusionauth.io/docs/v1/tech/guides/multi-tenant https://fusionauth.io/docs/v1/tech/guides/multi-tenant . There are of course other options too. Here are some I've heard of that seem like they fit your needs (offering some combination of RBAC, SSO, and multi-tenancy), but I'd suggest doing a spike: * clerk.dev * workos * supertokens * propelauth You could also start off with an open source solution like devise/omniauth (if building on rails) or passport.js (if building on JS). I'd only go down this path if you are familiar with the tech, as it can be difficult to configure if it is your first time, and, again, this is critical but undifferentiated functionality.
- sebmellen 4y ago
  IMO https://ory.sh https://ory.sh has completely changed this calculation. With the help of Ory Kratos it makes sense to roll your own auth.
  - mooreds 4y ago
    Do you mean to use Ory Kratos in a self-hosted manner? From a brief look it seems like you aren't rolling your own auth when you use this, but rather integrating it into your application. What am I missing?
    - sebmellen 4y ago
      Kratos is not a complete Auth solution - if you self host you still need to write your own UI. We built another layer over it to handle RBAC and organization management. But at least Kratos covers all the complex crypto and security items related to authentication (not authorization, which I consider to be a part of “auth” writ large).
x0x0 4y ago
Background: cofounded an enterprise saas company. I like this coverage of tech, though it's missing soc2 which will be required. And 27001 eventually. I disagree on making it easy for admins to add users. Just don't: rather, implement (a bit of) scim or jit user creation with the idp flows. The big thing it's missing is sales. This software is sold not bought. In any sales process with 3 different constituencies (users who really don't matter much, a champion, and an economic buyer) you need talented sales people. Bluntly, the vast majority of b2b / midmarket or enterprise tech companies are dead without an exceptional salesperson as a founder. The reason is that you have to sell your first 10 deals while the software basically doesn't work. Realistically, tech matters less than sales here. When you look at your risks, tech falls well below sales and execution risks, because you're highly unlikely to be building something that's never been built before. ie it's not like google, which basically was build a significantly better search engine using novel relevance tech. Almost all midmarket or enterprise saas products have no novel technology inside them. (Which is not to say that you don't have to build a high-quality implementation: you do. But "can we build this / can we make it work" is rarely a top risk.)
- stevesimmons 4y ago
  When would you prioritise SOC2 before ISO27001? And when the other way around?
  - x0x0 4y ago
    I'm not an expert on this, but I'd start with a soc2 type 2. soc2 served us well in the US. Some of Europe prefers 27001, but we sold into the EU with just a soc2 in the beginning. a soc2 is also a choose-your-own-adventure cert: you describe your processes (within constraints imposed by the goals you must achieve per the soc2 principles), and then you get audited on following your process.
- moneywoes 4y ago
  How did you build your sales skills and get those first 10 customers? Like I want to Build a property saas should I start prospecting first
roflyear 4y ago
Don't do soc just to do it. It's a lot of overhead if you don't need it, and your clients if they require it should give you a grace period.
dieselgate 4y ago
I wasn't familiar with the acronym RBAC (but certainly familiar with the concept) until web searching for it. First link was from solarwinds.. nope, found an okta link.. yep! Thanks for the well thought out list this was helpful
- twojacobtwo 4y ago
  Since I had the same experience just now, it seems useful to post the answer here. In computer systems security, role-based access control (RBAC) or role-based security is an approach to restricting system access to authorized users. It is an approach to implement mandatory access control (MAC) or discretionary access control (DAC). https://en.m.wikipedia.org/wiki/Role-based_access_control https://en.m.wikipedia.org/wiki/Role-based_access_control
  - dieselgate 4y ago
    Thanks for the call out
throwaway20222 4y ago
This is a really solid reply - I would emphasize “know your buyer.” We thought we had a solution to a problem. We were told from the end users we had a solution to the problem. We thought we knew the value to those people as far as pricing for the product. But the actual buyer didn’t at all value our product the way the end user did, especially when factoring switching costs etc and it was crippling.
ajax33 4y ago
This is a really good list. I head engineering for an enterprise SaaS startup in the manufacturing space. Wanted to add a few points to this: 1. Software Integrations: Enterprise software is almost never deployed in a vacuum. There will be a ton of existing software that companies use that they would want you to integrate with - most commonly being either some CRM like Salesforce or an ERP like SAP, Oracle. When pitching to a customer, it would be great to try and learn what existing software tools they use and see if opportunities exist to try and integrate with them ultimately. This will make your software very very hard for them to get rid off later and will also help distinguish you from your competitors who might try to be avoiding integrations. Designing your architecture with integrations in mind is a good idea. 2. Audit logs: Depending on the industry, there might be a strong requirement for compliance/auditing. The enterprise would want to ensure that every action undertaken on the platform is audited and can be reviewed on-demand later. 3. On-premise vs Cloud deployments: You might find certain clients that operate their own hardware and software and want you to just hand them some executable that they can deploy in their systems. On the other hand you'll also find companies that have gone all-in on cloud and won't bat an eyelid as long as you are deployed on some known cloud like Azure, AWS or GCP. Increasingly more and more companies are going the private cloud route and ask you to deploy on their cloud accounts (most commonly Azure - Microsoft has a much stronger hold on the enterprise market). Be prepared to handle requests like these. In several cases, you might be able push to have the SaaS being served from your cloud accounts but not always. 4. IT departments: Enterprise companies will invariably have an IT department that is supposed to ensure that the procurement process goes smoothly from a technical perspective and that you are compliant with all of their technical requirements. Their primary job is to ensure their asses are covered and nobody blames them later for technical/compliance issues later. Do not cut them out of the sales process. While they don't have the ability to approve the sale, they definitely have the ability to block it. Involve them closely and get their strong buy-in so that they don't become a bottleneck later.
- john_the_writer 4y ago
  If you can avoid ON-premise do so. Unless you have full control. I've had a few rails apps go pear shape when the customer updates their ruby version. Then fixing the app is on me. I spent weeks building an app, and I send it out in a nice package. 18 months later I get a call telling me it stopped working. I (being honourable) looked into the issue (free of charge). When I found out they'd updated their OS and Ruby version I bowed out. There's a line between building something and maintaining it for free for ever.
jollofricepeas 4y ago
I disagree. I manage a multi-million security tools and services budget for a Fortune 20. MY ADVICE: Focus on go-to-market strategy and value proposition before figuring out security. REASONS: 1. We dodge salespeople like the plague. There’s a reason enterprise sales timelines are 18 months. If we don’t want you first, then expect to chase us for a year plus trying to convince us. 2. Enterprises of a decent size usually have a vendor/supplier/third party risk program. If your service is identified as low risk, then we may have little to no requirements for you. Everyone doesn’t need to provide a SOC2 Type II, align with NIST or certify ISO. 3. Mine your network for prospective enterprise design partners and build something that meets their needs. As your product grows in risk, they’ll let you know what you need to have in order to win or keep their business. ADVICE: - Focusing in security before you have a product is a direct route to failure. - Providing a service that doesn’t require handling sensitive enterprise data means less requirements and quicker onboarding
john_the_writer 4y ago
I don't agree with the multi-tenancy. I've been part of two start ups that cracked the 3 million user mark (from staff to 3 million +). They all lived happily on one postgresql database. We didn't even consider breaking the DB apart until near this point. When we did we had the income to support the staff. I'd say don't build for scale. When you need it, you'll be making enough to pay for it. Even if you have to start over, you're income will pay the devs.
- brickers 4y ago
  I took multi-tenancy here to mean that you have multiple customers on the same instance of your software, with separate user/data control, admins, configuration, etc for each customer, rather than what youve described with databases.

mywacaday 4y ago

Some great points there. I would also add a way for business users or admins to easily review accounts and privileges and sign off on that review if you are targeting any kind of regulated industry.

vishnugupta 4y ago
+100. Look up maker-checker [1]. Almost all the enterprise systems require a human to review and approve changes initiated by someone else. Even if you don't implement it right away, be aware of it and if possible build your entity/data model such a way you can add it later without turning your architecture upside down. [1] https://en.wikipedia.org/wiki/Maker-checker https://en.wikipedia.org/wiki/Maker-checker

NetOpWibby 4y ago

This is excellent, thank you!

bradgessler 4y ago

https://www.enterpriseready.io/ https://www.enterpriseready.io/ is a good starting place that enumerates most of the great points made in the parent comment.

mooreds 4y ago

Disclosure: I work for an auth service vendor. Great feedback about knowing who the buyer is. Lots of folks think about the user, but knowing the buyer (and they are usually not the same person) is critical too. If you are a building a SaaS, I'd recommend outsourcing your auth, since that is both critical and undifferentiated functionality. There are lots of solutions out there. FusionAuth is one option (I work there); here's our multi-tenant guide: https://fusionauth.io/docs/v1/tech/guides/multi-tenant https://fusionauth.io/docs/v1/tech/guides/multi-tenant . There are of course other options too. Here are some I've heard of that seem like they fit your needs (offering some combination of RBAC, SSO, and multi-tenancy), but I'd suggest doing a spike: * clerk.dev * workos * supertokens * propelauth You could also start off with an open source solution like devise/omniauth (if building on rails) or passport.js (if building on JS). I'd only go down this path if you are familiar with the tech, as it can be difficult to configure if it is your first time, and, again, this is critical but undifferentiated functionality.

sebmellen 4y ago
IMO https://ory.sh https://ory.sh has completely changed this calculation. With the help of Ory Kratos it makes sense to roll your own auth.
- mooreds 4y ago
  Do you mean to use Ory Kratos in a self-hosted manner? From a brief look it seems like you aren't rolling your own auth when you use this, but rather integrating it into your application. What am I missing?
  - sebmellen 4y ago
    Kratos is not a complete Auth solution - if you self host you still need to write your own UI. We built another layer over it to handle RBAC and organization management. But at least Kratos covers all the complex crypto and security items related to authentication (not authorization, which I consider to be a part of “auth” writ large).

x0x0 4y ago

Background: cofounded an enterprise saas company. I like this coverage of tech, though it's missing soc2 which will be required. And 27001 eventually. I disagree on making it easy for admins to add users. Just don't: rather, implement (a bit of) scim or jit user creation with the idp flows. The big thing it's missing is sales. This software is sold not bought. In any sales process with 3 different constituencies (users who really don't matter much, a champion, and an economic buyer) you need talented sales people. Bluntly, the vast majority of b2b / midmarket or enterprise tech companies are dead without an exceptional salesperson as a founder. The reason is that you have to sell your first 10 deals while the software basically doesn't work. Realistically, tech matters less than sales here. When you look at your risks, tech falls well below sales and execution risks, because you're highly unlikely to be building something that's never been built before. ie it's not like google, which basically was build a significantly better search engine using novel relevance tech. Almost all midmarket or enterprise saas products have no novel technology inside them. (Which is not to say that you don't have to build a high-quality implementation: you do. But "can we build this / can we make it work" is rarely a top risk.)

stevesimmons 4y ago
When would you prioritise SOC2 before ISO27001? And when the other way around?
- x0x0 4y ago
  I'm not an expert on this, but I'd start with a soc2 type 2. soc2 served us well in the US. Some of Europe prefers 27001, but we sold into the EU with just a soc2 in the beginning. a soc2 is also a choose-your-own-adventure cert: you describe your processes (within constraints imposed by the goals you must achieve per the soc2 principles), and then you get audited on following your process.
moneywoes 4y ago
How did you build your sales skills and get those first 10 customers? Like I want to Build a property saas should I start prospecting first

roflyear 4y ago

Don't do soc just to do it. It's a lot of overhead if you don't need it, and your clients if they require it should give you a grace period.

dieselgate 4y ago

I wasn't familiar with the acronym RBAC (but certainly familiar with the concept) until web searching for it. First link was from solarwinds.. nope, found an okta link.. yep! Thanks for the well thought out list this was helpful

twojacobtwo 4y ago
Since I had the same experience just now, it seems useful to post the answer here. In computer systems security, role-based access control (RBAC) or role-based security is an approach to restricting system access to authorized users. It is an approach to implement mandatory access control (MAC) or discretionary access control (DAC). https://en.m.wikipedia.org/wiki/Role-based_access_control https://en.m.wikipedia.org/wiki/Role-based_access_control
- dieselgate 4y ago
  Thanks for the call out

throwaway20222 4y ago

This is a really solid reply - I would emphasize “know your buyer.” We thought we had a solution to a problem. We were told from the end users we had a solution to the problem. We thought we knew the value to those people as far as pricing for the product. But the actual buyer didn’t at all value our product the way the end user did, especially when factoring switching costs etc and it was crippling.

ajax33 4y ago

This is a really good list. I head engineering for an enterprise SaaS startup in the manufacturing space. Wanted to add a few points to this: 1. Software Integrations: Enterprise software is almost never deployed in a vacuum. There will be a ton of existing software that companies use that they would want you to integrate with - most commonly being either some CRM like Salesforce or an ERP like SAP, Oracle. When pitching to a customer, it would be great to try and learn what existing software tools they use and see if opportunities exist to try and integrate with them ultimately. This will make your software very very hard for them to get rid off later and will also help distinguish you from your competitors who might try to be avoiding integrations. Designing your architecture with integrations in mind is a good idea. 2. Audit logs: Depending on the industry, there might be a strong requirement for compliance/auditing. The enterprise would want to ensure that every action undertaken on the platform is audited and can be reviewed on-demand later. 3. On-premise vs Cloud deployments: You might find certain clients that operate their own hardware and software and want you to just hand them some executable that they can deploy in their systems. On the other hand you'll also find companies that have gone all-in on cloud and won't bat an eyelid as long as you are deployed on some known cloud like Azure, AWS or GCP. Increasingly more and more companies are going the private cloud route and ask you to deploy on their cloud accounts (most commonly Azure - Microsoft has a much stronger hold on the enterprise market). Be prepared to handle requests like these. In several cases, you might be able push to have the SaaS being served from your cloud accounts but not always. 4. IT departments: Enterprise companies will invariably have an IT department that is supposed to ensure that the procurement process goes smoothly from a technical perspective and that you are compliant with all of their technical requirements. Their primary job is to ensure their asses are covered and nobody blames them later for technical/compliance issues later. Do not cut them out of the sales process. While they don't have the ability to approve the sale, they definitely have the ability to block it. Involve them closely and get their strong buy-in so that they don't become a bottleneck later.

john_the_writer 4y ago
If you can avoid ON-premise do so. Unless you have full control. I've had a few rails apps go pear shape when the customer updates their ruby version. Then fixing the app is on me. I spent weeks building an app, and I send it out in a nice package. 18 months later I get a call telling me it stopped working. I (being honourable) looked into the issue (free of charge). When I found out they'd updated their OS and Ruby version I bowed out. There's a line between building something and maintaining it for free for ever.

jollofricepeas 4y ago

I disagree. I manage a multi-million security tools and services budget for a Fortune 20. MY ADVICE: Focus on go-to-market strategy and value proposition before figuring out security. REASONS: 1. We dodge salespeople like the plague. There’s a reason enterprise sales timelines are 18 months. If we don’t want you first, then expect to chase us for a year plus trying to convince us. 2. Enterprises of a decent size usually have a vendor/supplier/third party risk program. If your service is identified as low risk, then we may have little to no requirements for you. Everyone doesn’t need to provide a SOC2 Type II, align with NIST or certify ISO. 3. Mine your network for prospective enterprise design partners and build something that meets their needs. As your product grows in risk, they’ll let you know what you need to have in order to win or keep their business. ADVICE: - Focusing in security before you have a product is a direct route to failure. - Providing a service that doesn’t require handling sensitive enterprise data means less requirements and quicker onboarding

john_the_writer 4y ago

I don't agree with the multi-tenancy. I've been part of two start ups that cracked the 3 million user mark (from staff to 3 million +). They all lived happily on one postgresql database. We didn't even consider breaking the DB apart until near this point. When we did we had the income to support the staff. I'd say don't build for scale. When you need it, you'll be making enough to pay for it. Even if you have to start over, you're income will pay the devs.

brickers 4y ago
I took multi-tenancy here to mean that you have multiple customers on the same instance of your software, with separate user/data control, admins, configuration, etc for each customer, rather than what youve described with databases.