Apps for Good Showcase: Build a Digital Product Around a Real User

Editorial overview

The most revealing fact about the Apps for Good Showcase is not that students make app ideas; it is that the idea carries more weight than the polish. In the published 2026 rules, judges weighted the idea four times, the product three times and the presentation once. That balance rewards teams that can define a worthwhile problem, understand the people affected and make sensible product choices. A sophisticated prototype cannot rescue a vague user need, while a focused concept can remain competitive even if it is not fully coded.

The 2026 results show what this looks like in practice. Bookworm, the People’s Choice winner, addressed falling reading habits through streaks, a digital library and social progress features. Other recognised ideas tackled fast fashion, racism, social anxiety and local heritage. Across 251 entries, 179 industry volunteers completed 3,468 reviews before finalist panels met five teams. CompeteMap’s view is that the Showcase works best as the public outcome of an Apps for Good course, not as a stand-alone weekend hackathon. Students need enough time to investigate a real audience, reduce the problem to a credible product and explain why each feature belongs. The main trade-off is access: entry is relatively open within UK primary, secondary and home education, but students must first complete an eligible Apps for Good course in the same academic year.

Quick Facts

Review Evaluation

Rated Intermediate. The Showcase combines moderate skill demand with a light entry barrier, short preparation load and a standard complete submission. Students need to connect research, product decisions and communication, but the official criteria do not require a technically advanced finished app. The course-completion requirement is the main gateway.

What the Showcase actually asks students to do

The Apps for Good Showcase is the annual competition attached to Apps for Good’s learning programme. An individual or team must have completed an Apps for Good course during the same academic year; this can include a home-study course, club or enrichment activity. Entrants must be in UK primary or secondary education, home education or an equivalent setting, and no team member may have been older than 18 at the start of the academic year.

This matters because the competition is not asking for an unrelated app uploaded at the end of term. The submission grows out of the course’s problem statement and product work. The 2026 student guidance asked teams to identify their target users, explain the problem and why it matters, then show how the proposed product would address it. A teacher or the team could submit one entry per project, with the teacher receiving the confirmation and later status updates.

The latest completed cycle opened on 5 November 2025. Its published materials contain conflicting closing information: the formal rules state 24 June 2026, while a March organiser post advertised 24 April and the student page set finalist notification for 11 May. That inconsistency is a reason to follow the live entry form and educator emails, rather than plan from a single archived date. As of 8 September 2026, the organiser’s public Showcase page is still displaying the 2026 results and has not published a complete 2027 timetable.

How judging works

The Showcase uses two distinct decisions. First, industry volunteers and partner representatives review entries during shortlisting. Selected teams then become finalists and prepare a video or virtual pitch for a judging panel that may include sponsors and senior technology or business professionals. Shortlisted teams can also be included in the public People’s Choice process.

For 2026, the formal rules described three weighted areas:

The student-facing guidance uses slightly different labels—Idea, Solution and Entry—but points in the same direction. Reviewers assess how well the idea addresses the problem, how creative and thought-through the approach is, and how clearly the team explains it. Teams should therefore treat the pitch as evidence of their product reasoning, not as a substitute for it.

What the 2026 winners reveal

The recognised projects were not united by one technology. They were united by a specific audience and an understandable use case.

Bookworm, from The Judd School, proposed a reading app inspired by habit-forming learning products. It connected a familiar mechanism—streaks—to a defined concern: helping teenagers rebuild a regular reading habit. Just Own It reframed wardrobe sustainability around styling clothes people already own. Unity Hub drew on the team’s experiences to combine education, discussion and guidance around racism and discrimination. Luton Go joined local history, movement and location-based play.

These examples suggest three useful tests for a developing entry:

1. Can the team name the user more precisely than “everyone”?
2. Does each feature respond to an observed need or merely decorate the concept?
3. Can the team explain why this product would change a user’s behaviour or experience?

A team does not need to imitate the 2026 topics. It should imitate the discipline: begin with a recognisable problem, make the target audience visible and keep the product proposition narrow enough to explain.

A practical preparation sequence

1. Investigate before choosing features

Start with a small amount of defensible user research: short interviews, an age-appropriate survey, observation or reliable published evidence. Record what users struggle with, what they already do and why existing options fall short. Research should change the proposed product; otherwise it is only decoration.

2. Write one clear problem statement

The team should be able to complete this sentence: “For [specific users], [specific situation] creates [specific difficulty], because [evidence or insight].” If the statement requires several unrelated problems, the scope is too broad.

3. Prioritise the smallest credible product

List possible features, then keep only those needed for the main user journey. A wireframe or prototype should show how a person moves from their problem to a useful outcome. Coding may strengthen the evidence, but the official judging framework does not make technical complexity the sole objective.

4. Connect the pitch to the judging logic

A strong submission makes the chain visible: user evidence led to the problem definition; the problem led to particular features; testing or feedback led to revisions. The team should be able to explain one decision it changed after listening to a user.

5. Prepare for finalist questions

Finalists pitch to industry volunteers. Practise concise answers about users, feasibility, safeguarding, data use, accessibility and how the product would be tested. If the idea uses AI, the team should explain what the AI contributes, what could go wrong and where human oversight sits.

Common mistakes

Treating “tech for good” as a theme rather than a user problem

A broad ambition such as improving wellbeing or saving the planet does not yet define a product. Judges need to see who experiences the problem and what the proposed intervention changes.

Building too much before testing the premise

Time spent coding a large feature set is wasted if the intended users do not need it. Early sketches and conversations can expose a weak assumption more cheaply.

Using AI as the explanation

“Powered by AI” describes a tool, not a benefit. Teams should specify the input, output, risks and reason that this method suits the user better than a simpler alternative.

Assuming a polished video carries the entry

Presentation is part of the assessment, but the published weighting favours the underlying idea and product. Clear evidence and reasoning matter more than cinematic editing.

Ignoring permissions and ownership

The rules require original work or properly licensed material, necessary third-party permissions and lawful use of content. Teams should also read the licence granted to Apps for Good when an entry is submitted.

Where it fits in a computing pathway

Apps for Good sits on the product and social-innovation side of computing. It is a good match for students who enjoy interviewing users, designing interfaces, prototyping and pitching. It is not a substitute for an algorithmic contest, where performance depends on solving tightly specified programming problems against the clock.

For a broader map of those choices, read UK Computing Competition Pathway Explained and Bebras vs Raspberry Pi Foundation Coding Challenge vs British Informatics Olympiad. Students considering another product-based route can also compare the Congressional App Challenge guide, while checking its separate US eligibility rules.

Key Takeaways

• The Showcase is linked to completion of an Apps for Good course in the same academic year; it is not an open submission route for any pre-existing app.
• Official 2026 judging weighted the idea most heavily, followed by the product and then the presentation.
• A precise user problem and coherent feature set are more valuable than unnecessary technical complexity.
• Shortlisted teams progress from written or online entry evidence to a virtual industry pitch and possible People’s Choice participation.
• The 2026 cycle is complete, and a full 2027 timetable was not publicly available when this guide was checked.
• Because archived 2026 pages contain inconsistent closing information, entrants should follow the live entry form and educator communications for the next cycle.

Sources checked

• Apps for Good Showcase — checked 8 September 2026
• Apps for Good Showcase Rules 2026 — checked 8 September 2026
• Showcase information for students — checked 8 September 2026
• Showcase information for teachers — checked 8 September 2026
• Announcing the 2026 Apps for Good Showcase winners — checked 8 September 2026