These lessons learnt may apply to any hackathon.
Prototype not reinvent the wheel
Hackathons are meant for generating great ideas, fast and effectively. You don't have to invent a startup idea and build the entire company in 24 hours.
The sweet spot between BUSINESS and TECHNOLOGY
If your team is all engineers, or all business, all design... any 1+1 = 1 combinations, you may be running risk of group thinking, and not solving a real business / real world problem and provide a technical solution.
Ask yourself the question: what problems does my app / solution solve? Are they even relevant problems to these organizations? One mistake our team made was that we didn't get to talk to the NGO staff. We don't know what they really wanted.
Product > Feature > 1's and 0's
Real world solutions take product vision, not a bunch of fancy APIs or features chained together, and definitely not loose code libraries. Our apps had fancy mobile UI, overlay, panels and geolocation, but it sort of missed the point of solving the NGO's problem. Again, we didn't quite know the problems, because we didn't interview the user.
Hackathons take product management tactics, product vision, and technical skills, and productivity and efficiency via prototyping.
Under stress, teams crumble unless, the program management is skill, goal, and merit based. It's important to not get too personal. Fights will rise, 15 minutes before submission.
Teams can be formed before hand. There's strength in knowing "what to expect" from known teammates. Bootcamps and communities have found successful moments competing as a team. Hack reactor for example has students who scored winning positions and mentions on publications like TechCrunch.