3 ms·

Unfortunately, some services don’t allow this.

lolinder 2y ago
Ideally they would support SSO, but at a minimum any service that wants business customers will have accounts in some form. If they don't even have that then I would seriously second guess using them for anything in production. They're clearly not designed for businesses and can't be relied upon to not screw you up in serious ways.
- crazygringo 2y ago
  > but at a minimum any service that wants business customers will have accounts in some form. I mean, that's just not true. Plenty of successful and widely used businesses out there provide a single account/password for their service at a client company, rather than for each human user at that client company. It's a common pattern even if you think it shouldn't be. And yes they are designed for businsses and have business customers. For a lot of products, it's just not conceptually necessary to have multiple users for an account, i.e. support for "teams". It's a convenience that might be on the roadmap and might get done eventually, or not at all. Especially because supporting complex sets of user credentials can be a major project, which means another important feature doesn't get done instead.
  - lolinder 2y ago
    > And yes they are designed for businsses and have business customers. What I'm saying is that by definition these aren't designed for businesses. They might have business customers, they might even think that that's where their primary market is, but they're not designed for businesses if they use an account model that is designed for single consumer. And if they can't have been bothered to put together an account system then what else didn't they bother doing? I'm not buying the idea that an account system is just too complicated and would eat up too much time. There are only a few extra moving parts (teams, very basic roles) for an enormous quality of life improvement for the company (this entire thread would be largely unnecessary if every product a business used supported at least basic account management).
    - SkyPuncher 2y ago
      I think your definition is too rigid and unrealistic. While this example is cherry picked, it’s practical and real world. A studio is working on a project for a client. They want to share the work with the client. Setting up individual client accounts is both impractical and unnecessary. They instead opt for a single password to protect the project. This password is stored and shared by the client.
      - lolinder 2y ago
        Eh, I have a hard time even granting this one exception. The problem is turnover—a single password is fine when it's an individual who purchased the software. As soon as it's a company a shared password becomes untenable because people who are not intrinsically part of the company will need to know the password, and those people can and do leave. The only safe way to handle this is to reset your password every time someone leaves, and that's not scalable for any business with more than a dozen people and a dozen vendors. In your example, what path forward makes sense would depend on the project, but "single shared password" would be unsatisfactory to me as a client.
    - crazygringo 2y ago
      > I'm not buying the idea that an account system is just too complicated and would eat up too much time. Then why do you think there are all of these systems that don't have it? The CEO's/PM's aren't entirely stupid. They know what business customers are asking for, and what they're prioritizing in their asks, and how they're voting with their dollars. An account system is often going to come with different roles like admin, user, viewer, and then the entire product has to be overhauled to create display-only versions of what were workspaces where changes could be made, new role authentication checks on every API call and even every data operation, and so forth. It can actually be a relatively huge undertaking that winds up touching a majority of the code, that also adds to the scope of most future feature development in a non-trivial way. It's not just a table of users and passwords per account. I'm not saying it can't or shouldn't be done. I am saying that the idea that a companies without it "by definition aren't designed for businesses" is wrong, though. Not by definition, but by the reality of actual businesses today.

Ideally they would support SSO, but at a minimum any service that wants business customers will have accounts in some form. If they don't even have that then I would seriously second guess using them for anything in production. They're clearly not designed for businesses and can't be relied upon to not screw you up in serious ways.

crazygringo 2y ago
> but at a minimum any service that wants business customers will have accounts in some form. I mean, that's just not true. Plenty of successful and widely used businesses out there provide a single account/password for their service at a client company, rather than for each human user at that client company. It's a common pattern even if you think it shouldn't be. And yes they are designed for businsses and have business customers. For a lot of products, it's just not conceptually necessary to have multiple users for an account, i.e. support for "teams". It's a convenience that might be on the roadmap and might get done eventually, or not at all. Especially because supporting complex sets of user credentials can be a major project, which means another important feature doesn't get done instead.
- lolinder 2y ago
  > And yes they are designed for businsses and have business customers. What I'm saying is that by definition these aren't designed for businesses. They might have business customers, they might even think that that's where their primary market is, but they're not designed for businesses if they use an account model that is designed for single consumer. And if they can't have been bothered to put together an account system then what else didn't they bother doing? I'm not buying the idea that an account system is just too complicated and would eat up too much time. There are only a few extra moving parts (teams, very basic roles) for an enormous quality of life improvement for the company (this entire thread would be largely unnecessary if every product a business used supported at least basic account management).
  - SkyPuncher 2y ago
    I think your definition is too rigid and unrealistic. While this example is cherry picked, it’s practical and real world. A studio is working on a project for a client. They want to share the work with the client. Setting up individual client accounts is both impractical and unnecessary. They instead opt for a single password to protect the project. This password is stored and shared by the client.
    - lolinder 2y ago
      Eh, I have a hard time even granting this one exception. The problem is turnover—a single password is fine when it's an individual who purchased the software. As soon as it's a company a shared password becomes untenable because people who are not intrinsically part of the company will need to know the password, and those people can and do leave. The only safe way to handle this is to reset your password every time someone leaves, and that's not scalable for any business with more than a dozen people and a dozen vendors. In your example, what path forward makes sense would depend on the project, but "single shared password" would be unsatisfactory to me as a client.
  - crazygringo 2y ago
    > I'm not buying the idea that an account system is just too complicated and would eat up too much time. Then why do you think there are all of these systems that don't have it? The CEO's/PM's aren't entirely stupid. They know what business customers are asking for, and what they're prioritizing in their asks, and how they're voting with their dollars. An account system is often going to come with different roles like admin, user, viewer, and then the entire product has to be overhauled to create display-only versions of what were workspaces where changes could be made, new role authentication checks on every API call and even every data operation, and so forth. It can actually be a relatively huge undertaking that winds up touching a majority of the code, that also adds to the scope of most future feature development in a non-trivial way. It's not just a table of users and passwords per account. I'm not saying it can't or shouldn't be done. I am saying that the idea that a companies without it "by definition aren't designed for businesses" is wrong, though. Not by definition, but by the reality of actual businesses today.