While no company - or worse a startup - wants to consider this aspect, since the point of WhyGoSolo is to learn and connect with other people, I'm sharing this warts and all.

No matter what kind of company you are - funded, bootstrapped, government, Google, mISV, or the dream job that all of your developers have been dreaming about for years... Burnout Happens.

Sometimes it happens quickly.  If the work is boring, uninspired, or conditions/pay are bad, you can guarantee it happening quickly and without warning.  You may see this in horrible retention rates, the inability to recruit new people, or simple dissatisfaction within the team.  For example, a team I was with a few years ago suffered from all of the above.  I left in January of that year.  By mid-November, 7 of the 9 remaining team members had left... and none of the local recruiting companies were willing to work with them.

Sometimes it happens more slowly.  When the work is interesting, new problems are being solved, and/or people believe in the cause, it will take longer and there will be signs.  You'll see this in people being less productive, unable to focus, and making obvious mistakes.  Their heart just isn't in it.  Most often this is because of exhaustion and the desire/need 

So why is this relevant to WhyGoSolo?

For the past month, we've been pushing hard.  We've been pushing amazingly hard from top to bottom.  From Ann giving pitches and demos to the Dev team working on and through lots of code and tests to both Ann and I stradling both worlds.  To be honest, it's tiring... and if there's any time one of us will break and get burned out, this is the time.

Even worse, while a side project is just getting started - yes, WhyGoSolo is a side project for many of us - it's not work.  It's fun, it's new, it's a diversion from the difficult stuff.  But once you get towards launch, all those tedious things still need to be done... so most people want to disengage and look for something "fun" again.  And just to add insult to injury, no less than three of our team members have had major releases in their day jobs in the past few weeks.  Not an ideal environment at all.

So what are we doing to combat this?

1. Prioritize - We've broken the open issues (bugs, tweaks, and features) list down to a simple and straightforward hitlist of things that need to be addressed before the Demo.  Prior to the last couple days, we've had the big list unfiltered and it has caused confusion once or twice.  We don't plan on letting this happen again.
2. Drafting - No, we're not dragging people off the street, instead the team has been following the cycling model of Drafting.  It means that different people take the lead at different times, often to preserve the strength of the other riders.  In our case, as different people's dayjob schedules have been more/less demanding, different people have taken the lead at different times.
3. Milestones - Yes, we've already given one demo last week, but our big one is coming up this week at the Social Times DC Launch Event.  Having a finish line milestone that everyone can sink their teeth into and see something result is fundamental to making it.  Everyone can know that it won't go on forever.  That it can and will end.
4. Credit - While almost every team has a person or two who will push themselves beyond the point of exhaustion just to do it right with or without credit, the other 95% of the team will probably respond positively to encouragement.  It doesn't take much to identify the individuals who have made good contributions or have helped others do the same.  In the past couple weeks, a number of people have simply shined in their involvement.  I took time from our most recent call to identify them and plan to continue the practice indefinitely.
5. A Break - Once we get through this one, we're taking some time off to relax, regroup, and take some deep breaths.  At some companies, they give people a week of vacation time or send everyone out for drinks.  Since we're virtual, we can't do the exact same thing, but we may be able to come up with something.

And don't get me wrong.  We're not perfect and don't pretend to be.  We're working to solve the issues that come up externally or from the top down.  As the guy in charge, those are the ones I'm best situated and able to address but they're only a portion of what happens throughout our days.  Every team has issues that come from elsewhere and these fit into the burnout and exhaustion equation just as much if not more than the other things.

That's one of the joys of a 100% distributed team... we can't go into the next room and talk over coffee or read body language to understand or detect things immediately.  Instead, it takes reaching out to team members individually, regularly, and repeatedly to find out what's on their mind.  You have to build up trust and respect within the team and with the team to begin to address those...