[silentmars]

One downside to this approach is that it can tend to create status or power rifts between the product people and the tools people. In traditional shops, the "skills that pay the bills" product people often get better treatment, higher status, greater advancement opportunity and stronger job security than tooling people, who are often seen as being on the cost side of the business.

Startups that go down this route should be on the lookout for this potential for divisiveness and culture fragmentation.

[inthewoods]

The approach they seemed to take to deal with this was bringing in an outside developer. I'm not a fan of this approach for a number of reasons - but mainly because then you've got a dependency on a single outside person or firm to maintain that application going forward.

[noahbrier]

To answer both: On the division side, we have found a number of people who are simply more passionate about building products for their peers than building products for customers. I interviewed one last night, so I can confirm this is the case. Because the job includes a bit of product management and a bit of design, it ends up being something fundamentally different than what we ask engineers to do.

As for the outside devs, I agree that is a challenge and one of the things that ultimately led to us hiring internally to help support and continue to grow those internal products.