I can't answer this based on experience but its seems to me that the right approach to this is to pick from the big book of "agile" (certainly this is the approach I would take).
To take the two most obvious points
Do you need a leader
No, but you do need a product owner - someone who defines/champions the requirement. Beyond that the team needs to self-organise (though that might throw up a leader by default). There is an issue with where the buck stops (who decides) but practically you don't have time...
should a project have one feature
Yes, absolutely, you're working towards the minimum useable functionality - that's your first objective. Once you have minimum useable then you can add more - that might be an additional feature or it might be an improved UX for the feature you've already got.
To come back to organisation - do the things you'd want to do anyway, create a backlog of stories, prioritise them, queue them up, work through them in order (I appreciate there will be dependencies). What you want is a kanban style approach - limit your work in progress to the size of the team (and according to skills available) and let the stuff flow from left to right. Sticky notes arriving in the "done" column will help the stress levels.
If the team is large enough I think there's a strong case for pair-programming here - the aim being to reduce bugs by having two pairs of eyes on it from the off. At the very least try for quick and dirty code reviews early and often.
I know its a "hack", I know that that's supposed to mean "quick and dirty" but applying a good practice from the off should pay back towards the end of the day and regardless of where you end up you'll have something that shows that you made an effort (photograph your board (-:)