Janpeter Visser
fb4d2e093f
* docs(ST-1001..1008): add M10 — QR-pairing login milestone to backlog Plant acht stories ST-1001..ST-1008 voor password-loze inlog via QR-pairing. Mobiele bevestiging met UA+IP, demo-blokkade, paired-sessie 8u TTL. Security-uitgangspunt: mobileSecret reist alleen via QR-fragment + POST-body, desktop-SSE/claim via HttpOnly pre-auth cookie — geheim materiaal nooit in URL-paden, querystrings, access logs of browsergeschiedenis. Twee gescheiden hashes in DB (secret_hash + desktop_token_hash). Bouwt voort op M8 LISTEN/NOTIFY- infra met eigen channel scrum4me_pairing. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * chore(ST-1001..1008): teach backlog parser about M9 + M10 M9 (Actief Product Backlog) was bij eerdere merge per ongeluk overgeslagen in de drie milestone-maps; viel terug op fallbacks. Nu expliciet, samen met M10 (QR-pairing). Parser self-test toont 12 milestones / 118 stories / 190 tasks. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(ST-1001..1008): document QR-login flow in functional spec + persona Voeg F-01b (Inloggen via mobiel via QR-pairing) toe aan de functional spec met acceptatiecriteria, randgevallen en datamodel. Beveiligingsuitgangspunt expliciet: mobileSecret in URL-fragment en HttpOnly desktop-cookie zodat geheim materiaal nooit in URL-paden of access logs belandt. Lars-persona krijgt de bijbehorende use-case (publieke/geleende laptops bij klantbezoek of familie) zodat de feature een herkenbare aanleiding heeft in v1. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(ST-1001..1008): add M10 implementation plan + link from backlog Volledig implementatie-plan per story (Bestanden / Stappen / Aandachtspunten / Verificatie) in dezelfde stijl als M9. Citeert de patronen uit docs/patterns/iron-session.md, route-handler.md en server-action.md, en hergebruikt het LISTEN/NOTIFY-pattern uit app/api/realtime/solo/route.ts. Bevat ook commit/branch-strategie per laag, reseed-stap voor de MCP-context, en verificatie-acceptatie inclusief log-controle dat geheim materiaal niet in access logs belandt. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs: enforce one-branch-per-milestone policy to limit Vercel builds Vercel preview-deployments worden bij elke push naar een feature-branch getriggered en kosten op het Hobby-account budget. Voeg expliciete Branch & PR Strategy toe aan CLAUDE.md: één branch per milestone, commits accumuleren lokaal, push + PR pas na handmatige gebruiker-acceptatie. Uitzonderingen voor planning-only PR's (alleen docs) en hotfixes. Update tegelijk de branch/commit-strategie-tabel in het M10-implementatieplan zodat die de nieuwe policy weerspiegelt (één branch feat/M10-qr-login, chronologische commits per stap, push pas bij groene happy-path-acceptatie). Bevat een 'Wanneer aanpassen'-sectie zodat de regel makkelijk teruggedraaid kan worden zodra het account naar Pro gaat. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
8.8 KiB
DevPlanner — User Personas
Versie: 0.1 — april 2026 Volgt op: Concept & Feature Brainstorm v0.3
Persona-overzicht
| Naam | Leeftijd | Situatie | Primaire behoefte |
|---|---|---|---|
| Lars | 34 | Solo developer, 4 eigen SaaS-projecten naast zijn dagtaak | Overzicht houden zonder planningssysteem te worden |
| Dina | 28 | Freelance developer, werkt voor 3 klanten tegelijk | Klantprojecten gescheiden houden en voortgang aantonen |
| Remi | 41 | Lead van een klein team (3 personen), geen dedicated PM | Scrum licht toepassen zonder Jira-overhead |
Lars
Leeftijd: 34 — Situatie: Solo developer met 4 actieve side projects naast een fulltime baan
Achtergrond
Lars werkt overdag als backend developer bij een middelgroot bedrijf en bouwt 's avonds en in het weekend aan zijn eigen projecten: een SaaS-tool voor factuurverwerking, een open-source CLI-utility, een persoonlijk dashboard en een experimenteel AI-project. Hij werkt alleen, heeft geen teamleden en geen deadlines die van buitenaf worden opgelegd. Alles loopt via zijn hoofd of verspreide markdown-bestanden in de repositories zelf.
Een typische slechte avond
Hij opent zijn laptop na het werk en weet niet meer waar hij gebleven was. In welk project zat hij? Wat stond er open? Hij herinnert zich dat er vorige week een bug was gerapporteerd in de factuur-tool, maar hij weet niet meer of hij die heeft gefixt of alleen heeft opgeschreven. Hij besteedt twintig minuten aan het doorzoeken van commit-logs en README's voordat hij kan beginnen. Als Claude Code dan eindelijk een taak oppakt, is de context al kwijt.
Hoe hij het nu oplost
Elke repository heeft een TODO.md die hij bijhoudt zolang een project actief is. Als hij een week niet heeft gekeken, is het bestand achterhaald. Prioritering is impliciet — hij werkt aan wat op dat moment het interessantst voelt, niet aan wat het belangrijkst is. Jira heeft hij één keer geprobeerd voor zijn side projects: duurde twee uur om in te richten en stopte na drie weken.
Doelen met deze app
- Elke avond binnen één minuut weten welke taak het meest urgent is per project
- Claude Code laten oppakken wat open staat zonder zelf de context te hoeven herstellen
- Achteraf kunnen zien wat er gedaan is en hoe (implementatieplan, commit, testresultaat)
- Op klantbezoek of bij familie zijn side projects kunnen demonstreren op een geleende laptop, zonder dat hij zijn wachtwoord op een vreemd toetsenbord hoeft te typen — door zijn telefoon (waar hij al ingelogd is) een QR-code op het scherm te laten scannen
Frustraties om te vermijden
- Verplichte velden en formulieren die langer duren dan de taak zelf
- Systemen die vragen om updates die hij toch niet bijhoudt (daily standup-achtige inputs)
- Alles wat aanvoelt als "project management voor grote teams" — hij is de enige gebruiker
Relatie met technologie
Power user. Leeft in de terminal, gebruikt Claude Code dagelijks, bouwt zijn eigen tooling als iets hem niet bevalt. Wil een app die hij ook via een API kan aansturen.
Dina
Leeftijd: 28 — Situatie: Freelance full-stack developer, werkt parallel voor drie klanten
Achtergrond
Dina werkt als zelfstandige en heeft op dit moment drie lopende klantprojecten: een e-commerceplatform in onderhoudsfase, een nieuw admin-dashboard voor een logistiek bedrijf en een kleine MVP voor een startup. Elk project heeft zijn eigen ritme, zijn eigen repo en zijn eigen verwachtingen. Ze werkt alleen maar heeft per klant een contactpersoon die wil weten wat er gedaan is.
Een typische slechte dag
Ze heeft drie context-switches voor de lunch. Het logistiek-dashboard heeft een bugmelding binnengekomen, de startup wil een update, en de e-commerce klant heeft een vraag over iets wat twee Sprints geleden geleverd is. Ze heeft geen centraal overzicht — ze zoekt in Slack-threads, e-mails en commit-logs om te reconstrueren wat er wanneer gedaan is. Aan het eind van de dag heeft ze productief werk gedaan maar kan ze niet meer zeggen wat precies.
Hoe ze het nu oplost
Elk klantproject heeft een Notion-pagina met een ruwe takenlijst. Notion is flexible maar heeft geen structuur die Scrum-begrippen begrijpt. Ze heeft geprobeerd Trello te gebruiken maar het mist de hiërarchie die ze nodig heeft (project → feature → taak). Ze voelt dat ze iets robuusters nodig heeft nu het derde project erbij is gekomen.
Doelen met deze app
- Per klant een gestructureerde Product Backlog bijhouden zonder overlap
- Snel kunnen antwoorden op "wat heb je de afgelopen week gedaan?" met concrete verwijzingen naar commits en stories
- Claude Code gebruiken voor routinetaken zodat zij zich kan richten op complexere beslissingen
Frustraties om te vermijden
- Systemen waarbij klantdata vermengd raakt (ze wil strikte projectscheiding)
- Dashboards die statistieken tonen die ze niet nodig heeft (velocity, burndown)
- Alles wat ze verplicht dagelijks bij te houden — ze heeft soms een dag vrij of ziek
Relatie met technologie
Comfortabel maar niet fanatiek. Gebruikt VS Code, GitHub en een handvol SaaS-tools. Geen terminal-purist zoals Lars — ze gebruikt liever een goede UI dan een CLI als beide beschikbaar zijn.
Remi
Leeftijd: 41 — Situatie: Lead developer van een team van drie, zonder dedicated projectmanager
Achtergrond
Remi werkt bij een klein softwarebedrijf met in totaal acht mensen. Zijn team bestaat uit hemzelf en twee juniordevelopers. Ze bouwen interne tools voor twee afdelingen en onderhouden drie legacy-systemen. Er is geen Scrum Master, geen Product Owner en geen projectmanager — Remi doet dat er allemaal bij. Hij heeft Scrum gelezen en wil het toepassen, maar Jira is te zwaar en te duur voor hun schaal. Ze werken nu met een gedeeld Excel-bestand dat niemand consequent bijhoudt.
Een typische slechte week
Ze beginnen maandagochtend zonder duidelijk Sprint-doel. Iedereen werkt aan wat binnenkomt. Woensdag vraagt zijn manager naar de status van het rapportage-dashboard. Remi weet dat er aan gewerkt is maar niet hoe ver het is. Hij moet twee junioren ondervragen en drie feature-branches bekijken om een antwoord te kunnen geven. Vrijdagmiddag hebben ze een "retrospective" die eigenlijk een statusmeeting is.
Hoe hij het nu oplost
Excel voor taakregistratie, Teams-kanalen per project voor communicatie, GitHub Issues voor bugs. Drie systemen die niet met elkaar praten. Hij heeft Linear geprobeerd maar de leercurve was te groot voor de junioren. Hij zoekt iets dat hij in een middag kan inrichten en dat zijn teamleden zonder training kunnen gebruiken.
Doelen met deze app
- Elke Sprint starten met een duidelijk Sprint Goal dat iedereen ziet
- Wekelijks in één scherm kunnen zien wat open staat, wat in progress is en wat klaar is
- In de toekomst rollen kunnen toewijzen aan teamleden zodat de Product Owner (hijzelf) en de Developers (de junioren) gescheiden rechten hebben
Frustraties om te vermijden
- Alles wat de junioren extra werk geeft zonder directe waarde voor hen
- Rapportages en grafieken die hij niet nodig heeft
- Systemen waarbij hij afhankelijk is van een externe SaaS die duur wordt bij groei
Relatie met technologie
Ervaren developer, maar kiest bewust voor eenvoud. Wil een tool die hij zelf kan hosten als dat goedkoper uitpakt. Waardeert open source maar heeft geen tijd om een tool te onderhouden die hij zelf gebouwd heeft.
Persona-spanningen
| Spanning | Lars wil | Dina wil | Remi wil | Oplossing |
|---|---|---|---|---|
| API vs. UI | Alles via API en Claude Code | Goede UI, API is bonus | UI eerst, team moet het kunnen gebruiken | UI is primair; API is volwaardige burgerklasse, niet bijzaak |
| Eén vs. meerdere gebruikers | Altijd solo | Solo maar met klantcontext | Team van 3 met rolscheiding | v1 is solo; rolbeheer is v1-fundament voor v2-teamuitbreiding |
| Scrum-striktheid | Licht, pragmatisch | Structuur helpt maar geen dogma | Wil Scrum leren toepassen | Scrum-terminologie consistent; events zijn optioneel, niet verplicht |
| Zichtbaarheid voortgang | Eigen overzicht, geen rapportages | Klantverantwoording via commits | Teamstatus in één scherm | Activiteitenlog per story volstaat voor alle drie; aparte rapportagelaag is v2 |
Primaire persona
Lars is de primaire designtarget voor v1.
Rationale: Lars vertegenwoordigt de meest veeleisende gebruiker in termen van API-integratie en Claude Code-koppeling — de kern-differentiator van DevPlanner. Als de app goed werkt voor Lars (solo, API-gedreven, meerdere projecten, minimale overhead), werkt het ook voor Dina (zelfde gebruik, lichtere techvoorkeur). Remi's behoeften — teamgebruik en rolscheiding — zijn bewust naar v2 verschoven; het fundament (rolmodel in de datastructuur) wordt in v1 al gelegd.
Een feature die Lars zou doen stoppen — verplichte velden, trage UI, geen API — wordt niet gebouwd, ook niet als Remi er baat bij zou hebben.