The heart of Luro has always been a tool to enable deeper collaboration in a broader team context, so we architected it that way (a few times). It’s important that teams working on the same app are able to look at the product with the same lens of understanding, not just through their own silos. So teams were an early alpha feature of Luro.

I don’t regret choosing the teams path, but if I were building it all over again I would heavily reconsider focusing on single users first and then iterating towards team workspaces as the sales cycle starts rolling. In ActiveRecord parlance…

  • Stage 1: User hasOne Workspace - user can create a workspace themselves ($)
  • Stage 2: User hasMany Workspaces - user can create many workspaces themselves ($$)
  • Stage 3: User hasAndBelongsToMany Workspaces - user can invite other users ($$$)
  • Stage 4: Workspace belongsTo Organization - org now owns the workspace not a single user ($$$$)

This isn’t super innovative but there’s a multitude of benefits to this approach:

  • Always useful: At each phase you have a product that is useful to individual users, you’re never waiting on entire teams to onboard for a feature to be useful.
  • Tighter feedback loop: It might be weeks or months before you know a feature is working in a team context1, whereas single users have an instant “build → release → feedback” loop.
  • Value prop confidence: If it’s useful for one, it’s probably useful to many.
  • Easier user personas: If you’re leveraging user personas as abstractions, single users are easier to project whereas teams are a compound of different personas.
  • Easier metrics: One user = one workspace has a lot less dimensionality and calculus on how features are performing.
  • Faster path to revenue: If it’s useful, people will pay for it. Getting a single user to swipe a credit card is easier than getting a team thru a procurement process.
  • Straightforward payment integration: One user = one subscription is easier than one team = subscription level × number of seats, etc.
  • Revenue funds future development: Those single user plans fund future development for team workspaces
  • Faster pricing validation: If you’re taking money, you’ll find out what people are willing to pay real quick.
  • Easier conversations with VCs: Traction and revenue projections are easier if you have paying customers, easy math to abstract that to teams.
  • Easier self-service: Sign up → Get Workspace is less steps than Sign up → Create Org → Setup Workspace → Invite Teammates → Manage permissions
  • Less UI: No team picker, less onboarding, no user management, no user dropdowns
  • Less code: You don’t need an invite token system2, logic flows to invite users to teams, and lastViewedTeam state management.
  • Easier permission system: One user has access to all items in one workspace, then add complexity as necessary rather than starting with the complexity of an access control system.3
  • Easier testing: Testing invite and permission systems is costly and time consuming to account for all the potential states.
  • Solve hard problems later: What happens when two people edit the same document? You don’t have to solve problems like multiplayer data consistency on day one.
  • Faster iteration: Less code, easier testing, clear metrics, and pushing harder problems later in the process allows your product to stay nimble while working on product market fit.

Less code and a faster pathway to revenue are probably the biggest selling points to me. From a code standpoint you’d start with the most simplistic payment system imaginable (aside from one-time charges), have no invite system, and you’re delivering customer value the entire way. It’s a less riskier position and a pragmatic approach to building something with proven value over time.

That said, startups are risk taking ventures and are under pressure to scale fast. There’s way more money in enterprise team sales than individual sales. Multiplayer software like Slack, Discord, and Figma make collaboration a joy. Like I said, I don’t regret the path we took for Luro but for the reasons listed above I would heavily consider making a personal product rather than one for teams in my next venture.

  1. User A performs action → App sends User B email → User B checks email a week later → A week after that User B clicks the link because they talked about it in a meeting → Action that User A performed is old news now ↩

  2. Counterpoint, invites are a great way to build FOMO. ↩

  3. Counterpoint, a permission system is easier to add in at the beginning rather than layer in after the fact. ↩