And any app that is used to create/edit/publish anything of any kind WILL eventually be used by a team, whether you actively enable that or not. Password sharing is bad, don't encourage people to have to do that on your app.
-
-
Show this thread
-
And, just for the record, I have totally made this mistake multiple times, even after I knew better than to make it, because it's a super easy mistake to make when you're still in the early stages and "team stuff" doesn't seem like something you need yet.
Show this thread -
BTW, if you need to make this kind of separation late in the game, HMU.
Show this thread -
Also, since this thread is picking up a little steam, I believe internet protocol requires me to tell you that I sometimes post stuff on Soundcloud and Flickr if you're into those kinds of things. https://soundcloud.com/layercakewip https://www.flickr.com/photos/rhythmandcode/ …
Show this thread
End of conversation
New conversation -
-
-
This is a classic example of something you sadly don't want sucking up a bunch of time at the earliest phases of a company. Success can buy you the time to fix all manner of things, but the world's best user management has never made a company successful (Okta excepted).
-
I dunno Zack. I think it's good advice. I see this happening at every tech company I've worked at, and reworking the whole dashboard and permissions seems a lot more effort than just putting some thought into the user/account design in the first place.
-
In my experiences they manage to do it. They don't go out of business, it just takes a little (sadly annoying) time. On the other hand, I've seen scores of companies over engineer too early and actually go out of business without a product anyone actually wanted.
-
Just because something creates a future frustration doesn't mean it was a mistake. Startups are about moving as fast as possible and making a whole lot of compromises to survive long enough to get a chance to do it again with the next set of challenges.
-
I'm not saying to build out all of the user management and permissions first. I'm just saying take the extra 10 minutes to create an Account model that owns stuff. One User per Account is a fine place to start.
End of conversation
New conversation -
-
-
Best suggestion I've read on Twitter this week.
-
Another angle that I recently implemented - implement identities for users. One for FB login, one for email/password etc. Tidier than adding columns to user tables.
-
100x this, keeping a profile and identities apart is a great idea
- 1 more reply
New conversation -
-
-
This is great advice! We didn't do it for
@parseur and regretted it later. Did it from the start in@PriceurApp and it took a few extra minutes without adding noticeable complexity. Wish I read this advice a few years earlier!Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Also billing, like what AWS does with master accounts. Good for large companies with multiple teams/accounts.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Adding to this, subdomains help split those Accounts cleanly. God help you if you have to show things from several Accounts in one screen (which is the temptation with top-level apps) when you add in roles and permissions
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Very good advice. Yes, the initially registered used often ends up leaving but the organization stays intact. Billing should be attached to the org too IMO instead of an “owner” user.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Yes! Decoupling users and products FTW. This early decision can save lots of pain and rewrite dev time later.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.