Karte 12 · Kapitel capstone
Project build
🟢 USE — Run first
0 - 15 min
Show your MVP to a classmate — cold
At the start of this session, swap laptops with someone who has not seen your project. They will try to use your system without any explanation. Watch what happens.
- Open your MVP on your laptop. Hand it to your neighbour.
- Do not explain anything. Watch them use it.
- Write down: what did they try first? Where did they get confused? What did they ask?
- Swap back. Get your neighbour's notes.
- Identify the top two usability failures in your MVP.
- Fix one of them in the first 10 minutes before we move to the build phase.
Done-Signal: You have two identified usability failures written down and at least one fixed.
🔵 UNDERSTAND — Look inside
15 - 60 min
Iterating on a live system
A build session is not about adding features — it is about making what you have actually work. Most improvements come from running your system on real cases it was not designed for.
🧪 Test case design
Structured testing
Run five test cases you did not design for. At least one adversarial (trying to break the system). At least one from a colleague's data, not yours.
🔧 Fix loop
Iterative repair
For each failure: identify whether it is a prompt issue, a data issue, or a logic issue. Fix only that — do not refactor everything.
📸 Evidence capture
Demo preparation
For every successful test case, capture the input, output, and time taken. This is your demo material.
A system that works on the cases you designed it for is not validated — it is overfitted. Real validation means running cases you did not anticipate. The goal is not to add features but to find the edge of what your current MVP handles.
Probe-Fragen
- What is the most surprising way your system failed during the peer test? Was it a model failure, data format issue, or logic error?
- What is the slowest part of your pipeline? Is speed a constraint for your users?
- If you could only fix one thing before the demo, what would it be? Fix that first.
🟠 BUILD — Make it yours
60 - 90 min
Run five test cases and fix two failures
Structured build time. Run your MVP on five real cases, document every failure, fix the two highest-impact ones.
Aufgabe: Validate your MVP against five test cases. Document inputs, outputs, and failures. Fix the two highest-impact failures.
- List five test cases: one easy, two edge cases, one adversarial, one from a colleague's data.
- Run each case. Record: input | expected | actual | pass/fail | failure type.
- Identify the two highest-impact failures.
- Fix those two. Write one sentence per fix explaining what was wrong and what you changed.
- Re-run the fixed test cases. Verify they now pass.
- Take screenshots of your five test cases with results.
Deliverable: Test log (5 cases, results, failure analysis) + screenshots of fixed cases.
✓ SELF-CHECK
Hast du das verstanden?
- I ran five test cases on my MVP.
- I identified failure types (prompt / data / logic) for each failure.
- I fixed at least two failures and verified the fix.
After running real test cases, how has your understanding of the system's limitations changed? What would you design differently if you were starting over?
💬 KI-TUTOR
Frag den Tutor zu dieser Karte
Sokratisch: der Tutor antwortet mit Leitfragen statt fertigen Antworten — du erarbeitest die Lösung selbst.
Stell eine erste Frage zu dieser Karte unten.