6 ms·

I used to be of the opinion that the technical people did all the hard work and hence they should get the majority of the equity. However, once I tried to do ev

by adj 14y ago

I used to be of the opinion that the technical people did all the hard work and hence they should get the majority of the equity. However, once I tried to do everything myself I realised that the technical side was only one piece of the puzzle. Business, design and marketing may not be as intellectual as programming but they are no less hard and often more important. I really think that if two people are involved, the equity split should be 50/50 regardless of the skill set each one brings. If the equity is unbalanced, the level of effort each founder brings will be too.

ryanhuff 14y ago
The problem is that, often times, much of the technical work is front-loaded, leaving most of the initial risk disproportionately in the technical person's lap. It's only after an MVP is built that the business side of the operation has to perform. Equity split should reflect the assumed risk.
- adj 14y ago
  That’s a fair point. However, there could also be front loading in the business role. Sounding out the market, figuring out who your customers are and what they want - the sort of stuff that should be done before writing any code. Isn't that still a significant amount of work?
  - deleted 14y ago
    [deleted]
  - ryanhuff 14y ago
    If done right, I would agree with you that doing the up-front work you describe would lead to the most equitable outcome, especially if it involves booking sales or partnerships pre-MVP. Talking to customers in advance of MVP building, while a critically important part of product development, is often not given the rigor that it should though. I would strongly advise all involved to agree on measurable benchmarks, and perhaps even gate the product development progression on achieving these benchmarks.
creamyhorror 14y ago
1. Whether they're "no less hard" depends on who's doing it. 2. Many people claim they can do these things (at least, the "business" and "marketing" parts) - hence the surfeit of "nontechnical cofounders". But not all of them can. 3. There are fewer potential technical cofounders available in most areas. 4. Therefore, as a technical cofounder, you should pick only the best nontechnical partners, who will justify an even split of the equity. If you really don't find anyone who measures up in terms of demonstrated ability to hustle, connections that can actually be used, great business plans/prototypes and/or an impressive work ethic, then is it really worth starting up with a mediocre-or-worse cofounder? 5. If you insist on taking a nontech cofounder and you have only multiple mediocre suitors to pick from, it makes sense to me to offer less equity. If your potential partner feels it isn't fair, then look for someone else who understands that the product makers have precedence in this market. Personally, I think making a good business plan and doing marketing may be as hard as programming at times, but at this time, more people claim to be able to do business-side things than coding. That fact in itself justifies the tech cofounders' being picky with their partners. I think tech cofounders shouldn't let the thought that "oh, they work as hard as me" mislead them into partnering with someone who doesn't have capabilities that equal theirs, adjusted for supply and demand.

by adj 14y ago

ryanhuff 14y ago

The problem is that, often times, much of the technical work is front-loaded, leaving most of the initial risk disproportionately in the technical person's lap. It's only after an MVP is built that the business side of the operation has to perform. Equity split should reflect the assumed risk.

adj 14y ago
That’s a fair point. However, there could also be front loading in the business role. Sounding out the market, figuring out who your customers are and what they want - the sort of stuff that should be done before writing any code. Isn't that still a significant amount of work?
- deleted 14y ago
  [deleted]
- ryanhuff 14y ago
  If done right, I would agree with you that doing the up-front work you describe would lead to the most equitable outcome, especially if it involves booking sales or partnerships pre-MVP. Talking to customers in advance of MVP building, while a critically important part of product development, is often not given the rigor that it should though. I would strongly advise all involved to agree on measurable benchmarks, and perhaps even gate the product development progression on achieving these benchmarks.

creamyhorror 14y ago

1. Whether they're "no less hard" depends on who's doing it. 2. Many people claim they can do these things (at least, the "business" and "marketing" parts) - hence the surfeit of "nontechnical cofounders". But not all of them can. 3. There are fewer potential technical cofounders available in most areas. 4. Therefore, as a technical cofounder, you should pick only the best nontechnical partners, who will justify an even split of the equity. If you really don't find anyone who measures up in terms of demonstrated ability to hustle, connections that can actually be used, great business plans/prototypes and/or an impressive work ethic, then is it really worth starting up with a mediocre-or-worse cofounder? 5. If you insist on taking a nontech cofounder and you have only multiple mediocre suitors to pick from, it makes sense to me to offer less equity. If your potential partner feels it isn't fair, then look for someone else who understands that the product makers have precedence in this market. Personally, I think making a good business plan and doing marketing may be as hard as programming at times, but at this time, more people claim to be able to do business-side things than coding. That fact in itself justifies the tech cofounders' being picky with their partners. I think tech cofounders shouldn't let the thought that "oh, they work as hard as me" mislead them into partnering with someone who doesn't have capabilities that equal theirs, adjusted for supply and demand.