/COMPETITION // 17 OCTOBER 2026 // IN PERSON ONLY // TIME & LOCATION TBD

No Tutorial
This Time.
You Build It.

Competition day puts everything from the workshops into practice. Your team receives a challenge, plans a solution, builds a working web application, and presents the final result.

SEE HOW IT WORKS
jam_env.exe
~ $ source init_competition.sh
Loading environment variables...
> training_mode: disabled
> team_mode: enabled
> challenge: locked
> status: awaiting competition
~
RECEIVE → PLAN → BUILD → ADAPT → SUBMIT → PRESENT /// RECEIVE → PLAN → BUILD → ADAPT → SUBMIT → PRESENT /// RECEIVE → PLAN → BUILD → ADAPT → SUBMIT → PRESENT /// RECEIVE → PLAN → BUILD → ADAPT → SUBMIT → PRESENT ///

The Competition Loop

01 / RECEIVE

Teams receive the official application challenge and requirements.

02 / PLAN

Understand the requirements, divide responsibilities, design the solution, and decide how the application will work.

03 / BUILD

Turn the plan into a functional web application.

04 / ADAPT

Respond to new information or requirements introduced during the competition.

05 / SUBMIT

Finalize the application and submit the required project materials before the deadline.

06 / PRESENT

Demonstrate the finished application and explain the team's engineering decisions.

The output is simple.
Build something that works.

Teams will receive a web application challenge on competition day. You will be responsible for interpreting the requirements and deciding how to implement the solution.

!
NOTE: Exact challenge details remain locked until competition day.
localhost:3000/jam_process
challenge.md
requirements
architecture
implementation
working_web_app
jam_editor UTF-8
TEAM_WORKSPACE/
  • planning/
  • frontend/
  • backend/
  • testing/
  • presentation/
  • package.json
  • README.md
// System Architecture Configuration
export const appConfig = {
  api_endpoint: "/api/v1",
  features: ["auth", "dashboard"],
};
Frontend
Backend

Build as a team

There is no required team structure. Teams decide how to divide the work based on their strengths and strategy.

Whether you pair program on a single monitor, split strictly into frontend and backend, or have one person write tests while another builds UI—the process is entirely up to you.

EXPECT CHANGE.

Real software projects rarely stay exactly as planned. During the WebForge, teams should be prepared to adapt.

system_monitor.sh
> monitoring requirements...
> executing core build... [OK]
> running tests... [OK]
WARNING
event: requirements_changed
source: client_feedback
> recalculating architecture...

What are we looking for?

Projects are scored out of 100 points across seven categories.

Functional Completeness

20%

Does the application meet the provided requirements and function correctly?

> RUNNING DIAGNOSTIC...
STATUS: EVALUATING
[================> ]

Technical Implementation

20%

How effectively were authentication, persistent data, application logic, GitHub, and deployment implemented?

> ANALYZING STRUCTURE...
STATUS: EVALUATING
[========> ]

UI/UX & Design

15%

Is the application intuitive, coherent, responsive, and easy to use?

> TESTING INTERFACE...
STATUS: EVALUATING
[==================> ]

Problem Solving & Adaptability

20%

How effectively did the team debug problems and respond to the unexpected requirement change?

> MEASURING DELTA...
STATUS: EVALUATING
[====> ]

Final Demonstration

5%

Can the team clearly demonstrate and explain its solution?

> AWAITING DEMO...
STATUS: JUDGED LIVE
[ ]

System Understanding & Planning

10%

Can the team explain its Excalidraw diagram and how the major parts of the system interact?

> READING DIAGRAM...
STATUS: EVALUATING

Production Readiness & Performance

10%

Has the application been deployed correctly, connected to a domain, prepared for search discovery, and evaluated with PageSpeed Insights?

> CHECKING DEPLOYMENT...
STATUS: EVALUATING
// JUDGING PROCESS

What teams should prepare

01 / Required evidence

A working production URL, the GitHub repository, the final application, the Excalidraw system plan, and evidence that the team tested and measured the result.

02 / Live verification

Judges may navigate the deployed application, test core requirements, review authentication and persistent data, inspect responsive behavior, and ask the team to explain implementation decisions.

03 / Team demonstration

Present the problem, demonstrate the main user journey, explain the system, show how the change request was handled, and identify one challenge the team investigated.

04 / Completion check

Before submission, confirm required tasks are complete, team roles are clear, accounts and access work, materials are ready, dependencies are resolved, and the final production build has been verified.

The submitted version at the official deadline is the version evaluated. Judges apply the same published 100-point rubric to every team.

The Day

VIEW RULES
CHECK_IN
TIME TBD
CHALLENGE_RELEASE
TIME TBD
PLANNING
TIME TBD
DEVELOPMENT
TIME TBD
!
CHANGE_EVENT
TIME TBD
FINAL_BUILD
TIME TBD
SUBMISSION
TIME TBD
PRESENTATIONS
TIME TBD
RESULTS
TIME TBD

You already know the process.

The workshops give you the tools. Competition day tests what you can do with them.

LEARNING

Workshops

  • PLAN ✓
  • BUILD ✓
  • DEBUG ✓
  • SHIP ✓
→
PROVING

WebForge

  • HELP limited
  • TUTORIAL none
  • SOLUTION yours
jam_deploy.sh
$ jam --start
> checking team... [OK]
> checking skills... [OK]
> checking challenge...

====================================
challenge: LOCKED
event: WebForge 2026
status: READY
====================================

> await launch_sequence...

Think.
Build.
Adapt.
Ship.

"You will not know exactly what you are building until the challenge drops."