The practical side

Any community group, business, or faculty member with a real problem and real people behind it. You bring the problem and the access to learn about it honestly. We bring a student team and a coach. You stay involved: a kickoff conversation, introductions to the people who live the problem so the team can talk to them, and a few check-ins to react to what they find. You're a partner in the work, not a client waiting on a deliverable.

Every project starts by getting out of the building. Before the team builds anything, they go talk to the people who live the problem and test what they assumed against what they actually hear. That goes onto the team's canvas, which is just a running record of what they've learned and what they still need to figure out. Then they build something small, put it in front of people, and keep adjusting until it fits.

Then they change course, and that's the point. At each check-in the team makes a call: keep going because the evidence backs it up, or change direction because it doesn't. Changing course isn't a failure, it's the work doing its job. We'd rather a team catch it in week three than ship the wrong thing in week ten, because someone's waiting on the other end.

Most run within a single term. The first stretch is talking to people and figuring out the real problem; the second is building and testing. The thing that moves the timeline most is access, how fast the team can get in front of the people who live the problem. A sponsor who opens doors early makes it go faster.

Bringing a problem is free. What you give is time, context, and access to the people who feel the problem, which is the most useful thing you can offer. A lot of projects are part of a course, so students earn credit. Some get sponsored to go further, but that's never required. If the work needs to keep going after the term ends, we figure that out together.