3 ms·

> 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 h

> 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.

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.