Module 4 · Group project
Connecting to the World
A web application that gets its power from other systems' data, built with AI and owned line by line.
- 4–5
- students per team
- 4
- weeks
- 30
- minute presentation
- 24
- graded criteria
The mission
Almost every web application you use talks to dozens of other systems. In this project, yours does too.
The ability to exchange data with other services is one of the most important aspects of web applications. Your online bank is made up of dozens of internal systems. The Icelandic government offers services that run in completely different systems. When you search for your destination on Google Maps you are using several systems at once — and even io.vefskoli.is is made up of two.
The mechanism that lets these systems talk to one another is the API (Application Programming Interface): an abstract term for a way one system can use the resources or functionality of another.
Connecting APIs is one thing. Figuring out which connections would actually benefit your users is an art in itself, so it is crucial to understand the needs and expectations of the people who will use your application.
Talk to other systems
Live data from at least two APIs and one MCP server, combined into something none of them could do alone.
Solve a real user's problem
A design sprint finds the problem: interviews, analysis, brainstorming and testing with real users.
Mobile first, accessible
Designed for the small screen first, and usable by everyone, with or without a mouse.
Build with AI, own every line
Use AI freely, check its work, and be able to explain every line you ship.
Requirements
Based on the double diamond: diverge to understand, converge to decide.
- Run it from one schedule: the team picks the best one from its members' Design Sprint guide returns.
- Pick a facilitator and a decider, and time-box every activity.
- Find a problem worth solving, and interview real people about it.
- Brainstorm and sketch alone, then share and vote together.
- Test the prototype with real users, and change it from what they tell you.
- Plan where the team uses AI and where it doesn't. AI may prepare questions and sort notes; it never invents interviews, answers or users.
- A mobile-first lo-fi prototype.
- A style guide with smart components: text, boolean, instance swap and variant properties, named the way the code names them.
- Accessible from the start: AA in Stark for contrast, type and touch targets.
- Annotations for the developers: alt text, focus order, headings and landmarks.
- A polished hi-fi prototype built only from component instances.
This is the longest group project so far. Choose your tools, and argue the choice with what you learned in Module 3.
- A framework of your choice (React, Vue, Angular or something else), in TypeScript.
- Live data from at least two APIs, combined into something useful, with typed responses.
- At least one MCP server, with only the permissions it needs.
- Loading, empty and error states, and secret API keys that stay on the server.
- A component library: your team's design system in code, with props that match the Figma properties.
- A keyboard test and an axe scan that run in CI on every pull request.
Use AI freely, in any part of the project. The golden rule: if you can't explain a line, it doesn't belong in your project.
- Day 1, the team harness: one
AGENTS.md, your design-system skill, the tests, and CI on every pull request. - A human reviews every pull request, the agent's too.
- A notes page every day. A few bullets in your own words: what you asked, what the AI returned, what you changed and why, and what you learned.
- Then your agent adds its own account of the day: what it built (with commit hashes), where it was wrong and how that was caught. Save it as
report/notes/<date>-<your-name>.htmland commit it the same day. - Each student: an interactive code explanation page about a complex part of the code they own.
- The team: an AI report at
report/index.html, built from the notes: Try it, The problem, Decision log, What the AI got wrong, Code explanations, How we used AI.
- The final product must be available online for the general public.
- It looks and behaves like your hi-fi prototype.
- The whole main flow works with the keyboard only, with focus always visible.
What you hand in
Nice to have
Ideas
Better feedback on io.vefskoli.is
Make the feedback students give and get on their work more useful.
A Hall of Fame
Celebrate the best work from Vefskólinn students, past and present.
Under-used public APIs
Find open data nobody is making good use of, and build what it deserves.
The UN Sustainable Development Goals
Pick one of the 17 goals and build something that moves it forward.
Timeline
Discover
Start the design sprint, and give your agent its rules on day 1.
- Pick one sprint schedule, a facilitator and a decider
- Set up the team harness: AGENTS.md, skill, tests, CI
- Write a problem statement and interview real people
- Pick the APIs and the MCP server that could help
- Kick-off
- Tue 3 Nov
- Ends
- Fri 4 Dec
Presentation
Introduction · 5 min — Let the audience try it, show the product, and explain how you worked.
Scored here: 5 of the 24 criteria.
After the presentations everyone joins a common retro meeting.
How it's graded
Teachers, invited industry judges and the other students score your team from 0 to 10 on each criterion. Every criterion counts the same, so an area with more criteria carries more of the grade. Drag the sliders and watch the result.
The mean of all 24 criteria. The bar above shows how much of it each area carries.
Each criterion's score blends two juries. The panel — your teachers and the invited industry judges — carries 80%; the student audience carries the other 20%. Try one criterion:
A judge invited for design or for code only counts on that area and the presentation criteria. If only one jury scored a criterion, that jury's score is used on its own.
80% × 8.0 + 20% × 6.0
After the presentations you rate each teammate on contribution and teamwork, from −2 to +2. Your teachers read the ratings and confirm your figures, and those turn the team result into your grade. Pick a square:
Across: contribution. Down: teamwork. Each square is the change to the team result.
⚖️ Contribution 0 — Average
🤝 Teamwork 0 — Average(0 + 2) × (0 + 2) − 4 = 0 → ×1 (±0%)
The two figures multiply rather than average. Doing all the work while shutting the team out (+2, −2) is not “average”: it keeps 30% of the grade. The most a grade can rise is +30%; it can fall by as much as −70%.
Team result 7.0 × ±0%
Questions
Do we have to use a particular API?
No. Use any APIs that help your users, but at least two of them, plus at least one MCP server. Which ones is up to you.
Which framework do we use?
Your choice: React, Vue, Angular or something else. Argue the choice with what you learned in Module 3. TypeScript is required.
Can we use AI?
Yes, any tool, in any part of the project, with one exception: interviews and user tests are with real people. AI may help you prepare questions and sort your notes, but it never invents answers or users. We grade how well you understand your work, not how much AI you used.
What goes in the daily notes?
A few bullet points in your own words: what you asked, what the AI returned, what you changed and why, and what you learned. Then your agent turns the day into an HTML page with your notes word for word, followed by its own short, factual account. Don't commit raw chat transcripts: they can contain personal data or secret keys.
What if I can't explain part of our code?
Then it isn't ready to merge. Ask the AI to explain it, walk a teammate through it, or rewrite it until you can. AI use you declared in your notes is never penalised; what counts is whether you understand the result.
Does the product have to be online?
Yes. The final product must be available online for the general public, and the audience tries it during the presentation.
How is my own grade worked out?
From your team's result and how your teammates rate your contribution and teamwork. Try it in the grading section above.