The Congressional App Challenge is a U.S. House of Representatives competition for middle and high school students, judged separately in each congressional district. Judging weighs coding skill and the quality of the idea equally. So at CIT, before writing any code, students find a real problem in their own district using public data. This page shows that ideation process, in pictures.
Three criteria are scored at equal weight. Coding is one. The other two are which problem you chose and whether you solved it so people can actually use it. Choosing a good problem carries the same weight as building it well.
Equal weight across all three. There is no national theme; apps that solve a real local problem and actually work have scored well.
That is why we start with the idea. At this scale, the apps that stand out are not the flashiest — they are the ones that name a specific local problem and back it with real data. Finding that problem is the heart of ideation.
A good idea does not arrive all at once. It goes through four set steps. First the problem is opened wide and narrowed to one; then the solution is opened wide and narrowed to one. The two diamonds are that rhythm.
Collect frustrations people face in your district, without judging. Ten or more observations.
WidenPick the strongest one, dig to its root cause, and check it against real data.
NarrowOpen up many app ideas to solve that problem, from several angles. No judging yet.
WidenWeigh the candidates against criteria and settle on one, scoped to build in 3–4 months.
NarrowIf your child is not writing code in the first few weeks, that is normal. This is the stage for finding and sharpening a problem. Skipping it is what produces the most common entry in the competition.
This competition is judged district by district. So the starting point is not "what app is trending" but "what does our district actually struggle with." The five steps below apply to any district — a research order built for this competition.
Step A is confirming which district your home or school belongs to. Eligibility and district lookup are covered in the parent guide (dates & eligibility).
"Which problem to solve" is not decided from imagination. Students gather real material in four ways and write down the frustrations that keep recurring. The public statistics and field observations collected here become the evidence behind the idea.
Compare income, commute, internet access, language, and age against the national average. Each big gap is a daily inconvenience for someone.
Sort the city's 311 open data by category and scan recurring complaints on local forums. These are problems people already voice unprompted.
Map one real person's day hour by hour — a grandparent, a commuting sibling, a new neighbor — and mark every point where they wait, can't find, or give up.
Ask five people of different ages the same question: "What's harder than it should be around here?" Write the answers down exactly as spoken.
Rule for this stage: no app talk yet. Write only "seniors wait 40 minutes for the #44 bus" — not "let's build a bus app." The discipline of staying with the problem before jumping to a solution is the hardest part of ideation, and the line between a winning entry and a common one.
From the collected problems, pick one and write clearly who can't do what, and why. With the same topic, how concretely you've dug to the root cause decides whether it becomes a buildable problem or an unworkable sentence.
Don't stop at the visible symptom; ask "why?" repeatedly until you reach the real cause. Change the cause and the app you build changes too.
One public statistic shows the scale of the problem. Save the source.
One verbatim interview line shows the pain is real and current.
A quick search confirms nothing good exists yet for this neighborhood.
By this point the app comes not from imagination but from a chain of evidence. Below is how the earlier language-access problem leads to an app. Read left to right.
Score each candidate on five axes; if any one axis is weak, cut it or fix it. A strong idea fills all five evenly. This evidence-based filtering is the final step of ideation.
The five axes are feasibility · impact · originality · local fit · data. However good the spark, if one axis collapses it is hard to finish in 3–4 months.
CIT runs one 90-minute lesson a week across 16 sessions (15 weeks). The red and gold bands below are the research and ideation described above; the green build band comes after. Counting back from the October 26 deadline, a cohort should start in early July.
In the first four weeks there may be little to see on screen. The district brief and problem definition built in this period carry the eight weeks of development that follow. If the mid-point check at week 8 is behind, we cut scope to protect quality rather than add features.
This ideation process is not a competition-only skill. Reading a problem through data, observing real users, and deciding from evidence carry straight over to schoolwork and later projects.
Building the habit of confirming scale with public statistics instead of vague impressions.
Checking where real users get stuck by observation, not by assumption.
Weighing candidates by the same criteria and choosing one on grounds, not gut.
Learning to finish one core thing well instead of attempting everything and finishing nothing.
There is little you need to do at home. When your child asks "what's the most inconvenient thing around here?", tell them what you've actually experienced, and take a weekend walk around the neighborhood talking about what's hard. One problem your child observes becomes the starting point of the app.
Awards can't be guaranteed — outcomes depend on the number and level of entries, which vary by
district. This page introduces the ideation method covered in our lessons. Eligibility,
deliverables, and dates are in the
parent guide (dates & eligibility); for
questions, contact your teacher or jc@citcoding.com. Same approach for other competitions: Technovation · KSEF · KOAI.