Working is not the same as trustworthy
Security, accessibility and review, built into the loop, so quality becomes a habit rather than a panic before launch.
By the end of tonight you can
- Apply five security essentials and test your product for broken access control
- Run five accessibility checks without specialist tools, and fix or log what fails
- Automate a check up the ladder: working agreement → command → hook → CI
- Use Claude as a second reviewer: a subagent, /security-review and @claude on a pull request
- Run a sprint review and a retrospective that each end in a concrete change
OUTPUT · Slice 2 + quality checklist passed + sprint review notes
“It works on my machine” vs “people can trust it”
It works on my machine
- The happy path works when you click through it
- You’re logged in as the only user, with tidy test data
- You checked it once by hand, before the last three changes
People can trust it
- It refuses bad input, and people who aren’t allowed
- It works with a keyboard, a screen reader and at 200% zoom
- Checks run automatically every time, and someone else reviewed it
Tutors will trust TutorDesk with learners’ names and parents’ numbers. Earn that before launch, not after.
Security essentials
- SECRETSKeys and passwords live in a .env file that is never committed to Git
- AUTHENTICATIONUse your framework’s built-in login and password handling, not home-made code
- VALIDATIONCheck every input on the server; checks in the browser are easy to bypass
- LEAST DATACollect only what the slice needs: a learner’s first name, not a date of birth
- DEPENDENCIESEach package is someone else’s code: ask before adding one, and keep them updated
Then check authorisation on every request: who is asking, and do they own this record?
Change one number in the URL
“Tutors have to log in to see their bookings, so bookings are private.”
Log in as tutor Amira and open /bookings/41. Change it to /bookings/42. If Ben’s booking appears, the server checks who you are, not what you own. Every request must check ownership.
Ask
- Where else does your product put an ID in a URL or a form?
- What should Amira see at /bookings/42?
- Which test from Tuesday would have caught this?
- Why is “nobody will guess the number” no protection?
Accessibility checks you can run tonight
- KEYBOARDPut the mouse away: Tab through the form, see where focus is, submit with Enter
- ZOOMZoom the browser to 200%: nothing overlaps or needs sideways scrolling
- LABELSClick each field’s label: focus should move into that field
- CONTRASTRun the browser’s accessibility audit or a contrast checker on your text
- ERRORSSubmit it wrong: the message says what to fix in words, not only a red border
Five minutes, no specialist tools. Run them on every slice and log what fails.
The automation ladder
- AGREEMENTCLAUDE.md says “run the tests after each change and report the result”
- COMMAND/slice includes the test step, so every loop starts from the same checklist
- HOOKA setting runs the tests automatically after Claude edits a file; no one has to remember
- CIOn GitHub, the tests run on every push and pull request, whoever made the change
Climb when it matters: the more a mistake would cost, the less it should depend on memory.
A reviewer subagent, /security-review and a test hook
I’m building TutorDesk, a booking tool for independent tutors. I want a second reviewer that reads my changes before every commit, because I’m not a developer and can miss things. Please create a reviewer subagent in .claude/agents/reviewer.md. It should review the current changes against CLAUDE.md and our Definition of Done, looking hardest at: does every request check the user owns the record; is input validated on the server; are there tests for bad input and not allowed; are form fields labelled; [YOUR EXTRA CHECKS]. Good output is a short list ranked by risk: file and line – the issue – why it matters to a tutor – a suggested fix. When it can’t tell from the code, it should say it is unsure and what would settle it. Show me the file before you save it.
Check the response
- The agent file is short and says when to use it
- Each finding names a line and why it matters
- You decided on every finding; none were auto-applied
Human review vs Claude review: you need both
Claude’s review is good at
- Reading every changed line, every time, without getting tired
- Spotting known patterns: missing ownership checks, unchecked input, secrets in code
- Explaining a risk in plain English and proposing a fix you can test
Only people can judge
- Is this what tutors actually need, and does it match the evidence?
- Is this risk acceptable for us, at this stage, with this data?
- Does it feel right in use: the words, the flow, the tone of an error?
Claude’s review complements human judgement; it doesn’t replace it. A person approves every merge.
Sprint review and retrospective
- SPRINT REVIEWShow the working Increment to stakeholders and inspect it together
- PRODUCT GOALDiscuss progress toward the Product Goal and anything new in the evidence
- ADAPT BACKLOGLeave with an updated Product Backlog: what is next and what was dropped
- RETROSPECTIVEThe team inspects how it worked: people, process, tools, Definition of Done
- ONE CHANGEPick the most helpful improvement and put it into the next Sprint
The review inspects the product; the retrospective inspects how you build it. Both end in a change.
The Assemble gate: demo, then grade on two rails
- DEMOReal users try both slices in the sprint review; record who reached first value
- QUALITY SCORETests, human review, user evidence and your sign-off give Pass, Merit or Distinction
- CLAUDE’S REVIEWOne input to the quality score, never the verdict; a person decides
- MUST-PASSSecrets out of code, access checked on the server, least personal data
- DECISIONProceed, proceed with conditions, or go back: 07 if the grade is weak, 05 if the demo is
The grade says how good the slice is. Must-pass checks block it, whatever the score.
Workshop: Slice 2, quality pass, mini sprint review
Build Slice 2 with /slice, put both slices through the quality pass, then run a short sprint review and retrospective with a peer as your stakeholder.
- Build Slice 2 with /slice (TutorDesk: the tutor confirms; the learner sees it)
- Log in as a second user, change an ID in the URL, and commit a test that proves it is refused
- Run the five accessibility checks, /security-review and your reviewer; fix or log each finding
- Add the test hook (or ask Claude for a CI workflow) and show it running after a change
- Run a 6-minute sprint review and a 2-minute retro with a peer; write up both
Slice 2 + quality checklist + review notes in product/05-sprint-review.md
Quality rubric and the Assemble gate
- Slice 2 runs end to end, shown live: for TutorDesk, the tutor confirms and the learner sees it
- A committed test proves one user cannot see or change another user’s records
- Keyboard, zoom, label, contrast and error checks are logged, with each failure fixed or noted
- /security-review and the reviewer subagent ran; every finding is fixed or has a written reason
- A hook or CI runs the tests automatically, demonstrated on a change
- Review notes record feedback, backlog changes and one retrospective action with an owner
NEXT · Week 6: launch to first users. Bring both slices merged and your quality checklist.
© 2026 MVP Studios Ltd. MVPAI™ and the MVP Founders Programme materials are original works of MVP Studios Ltd. All rights reserved. No copying, redistribution or commercial use without written permission. Course terms