Feedback from 2016 told us that we should run several different levels of App Inventor sessions, not just one advanced session. So, this year, the sessions included a beginner and advanced session, to accommodate different amounts of experience with App Inventor. This, we hypothesized, would let attendees take away the more from the morning.As it turned out, with both sessions running concurrently, people could move between them as they felt necessary, which people did quite willingly and without hesitation. An improvement for next year, though, would be to offer descriptions of each level ahead of time. The descriptions should include a description of the range of experiences, if any, needed for any session. A small puzzle for future years remains, however. How can we appropriately differentiate within a session room for a group that you've never met before and may never meet again, that have very different experience levels, especially in the beginners session. A possible, partial solution, would be to have a very short survey ahead of time, asking 2 or 3 questions about programming experience. Another interesting observation was that there were big differences between adult and youth comfort learning programming. True to form, adults were generally less comfortable not knowing things and just exploring, compared to kids who were willing to jump in and try different things without fear of breaking things. As well, teachers and non-teachers behaved differently. Teachers recognized they were there to facilitate and seemed to feel less worry about how much they did or didn't understand. In the beginner room, most participants picked up programming with MIT App Inventor really quickly. This allowed time for teams to have the opportunity to share app ideas and then receive feedback from the room. Feedback came both on concept, and on how you might start planning implementations of some parts of the planned app with MIT App Inventor. This feedback opportunity brought to light an idea, namely that good apps do need good programming, but that programming can often be the "easy" part. Another part that is often considered secondary, but often has even more impact than the programming is the social or information system that's built around the app. For example, an anti-bullying app to allow reporting of incidents may require some programming, but requires much more focus on the social engineering, or providing the right incentives to each group of users to use the app. A drought monitoring app requires programming, but more focus on where to get the information needed to inform stakeholders, i.e. app users, about the state of watersheds. As the Technovation teams move forward with their ideas and coding of their apps, we hope that they, with the help of their mentors, will work to build the systems needs to make their apps and pitches successful and impactful in the world.