Employee #1: Dropbox

> We were all using the product so when there was funny stuff we tended to catch it.

I love this. There have been so many times I've run into a bug that makes me wonder if anyone on the engineering team actually used the product.

Hacker News #1: Shills.

Dogfooding is quite important, yeah. Some products, hmm, maybe not. For example, if I work for a dating app, I may not feel comfortable actually using the app myself especially when I am committed to a relationship. I.e. I can't dogfood it because I have no use of the product. In the case of say Facebook, I believe employees use the site internally so dogfooding is possible, even if privately some employees don't actually have a Facebook account. Going extreme, people who are responsible for designing military jet or nuclear reactor, they can't dogfood any of that, only simulation and model testing are possible.

For low barrier to entry products like facebook, dating sites, etc, I think companies are smart enough to build internal facing development only environments - so as a developer you won't be "using" the dating site, just using/testing/dogfooding the internal "dev" dating site that has maybe a million robots and all the employees, contractors, partners of the company.

If you haven't set down ground rules with a partner for working at a place like that, it's not a technical issue re: dogfooding, but a communication issue with your partner.

For things like military jets, nuclear reactors and the like, many times companies hire ex-military jet pilots (test pilots like for example Chuck Yeager), and former nuclear power plant operators, or even university profs who developed/calculated the nuclear fission equations in the first place (ie Manhattan Projected hired basically all nuclear physicists in all universities in the US for the effort) - they also do "testing" - which could be a form of dogfooding.

I was lucky enough to hear this story almost verbatim from Aston and it's so exhilarating to listen to how much fun everybody seemed to be having. He tells it with a lot of enthusiasm that you can feel just from the depth of his responses.

I think the one thing that stuck with me, personally, is the issues Dropbox had in the early days (TC 50 tech issues) and that it took six months to get Aston on board. From what I understand, pre-YC was not easy for Drew either.

As a stubbornly impatient person, this has to be hands-down the hardest part of building a startup. You're running an endless marathon as if your life depended on it, and you have to stop at the sidelines and calmly ask people if they'll run with you. And then be okay if they don't - because the course will change, and as it does it will become more attractive to different sets of people. You might see the finish line, but you have to understand that not everybody will see it the same way you do.

The thing that I'd add here is that Aston kind of downplays how important having a business model is as an employee / founder (at least per Drew joking around about pricing). I don't think he did this intentionally, but generally we're over saturated with these ideas that you just need a product people love. These stories inspire technical founders, but having a defensible business is something you should think about sooner rather than later. Not everybody can be a Dropbox, so learn as much as possible about every aspect of what your company can and will be, learn how to communicate that, and stack the deck in your favor. It's an ongoing process and I certainly am not one to claim mastery (far from it), but as somebody who's in the weeds it's the perspective I have.