Naar inhoud
Case
  • gwbo
  • Yoot Portaal
  • 2020–2023

Van losse e-mails naar een configureerbare projectworkflow

Yoot begon tijdens mijn stage bij gwbo met een praktische vraag: breng projectdocumenten uit verspreide e-mailboxen samen en maak zichtbaar wat nog ontbrak of beoordeeld moest worden. Terwijl we het werkproces beter leerden kennen, groeide die vraag uit tot een configureerbaar portaal met organisaties, projecten, projectsjablonen, dossierstappen en documentbeoordeling.

In het kort

Mijn verantwoordelijkheid
Van klantvraag, user stories en wireframes tot projectsjablonen, datamodel, Laravel-API en Nuxt-interface. Ook deployment, documentatie, begeleiding en overdracht.
De verandering
Van projectdocumenten verspreid over e-mailboxen naar één gedeelde projectworkflow voor ongeveer 25 gebruikers. Nog in gebruik bij mijn laatste bevestiging in 2026.
Visuele reconstructie van een Yoot Portaal-projectdossier met vereiste documenten, fasen, versies, statussen, eigenaars en acties om bewijs te openen of te uploaden.
Projectdossier – vereiste documenten, statussen en uploadactiesVisuele reconstructies van Yoot Portaal op basis van het oorspronkelijke productUitsnede van het scherm, het volledige scherm opent in de Gallery.

Context

gwbo adviseerde architecten, projectontwikkelaars en aannemers over energiezuinige woning- en utiliteitsbouw en werkte daarbij onder meer aan bodemenergiesystemen. Voor specifieke werkzaamheden aan zulke systemen gelden in Nederland erkennings- en kwaliteitsregelingen. Rond de start van Yoot werden de relevante richtlijnen vernieuwd, onder meer om de informatie-uitwisseling tussen betrokken partijen te verbeteren.

Yoot ondersteunde de projectadministratie rond dat werk. De applicatie certificeerde niemand en bepaalde niet zelfstandig of een document aan wettelijke eisen voldeed. De inhoudelijke beoordeling en verantwoordelijkheid bleven bij de betrokken specialisten en verantwoordelijke organisaties binnen het proces.

Bestaande klanten leverden de benodigde projectstukken vooral per e-mail aan. Bijlagen raakten verspreid over postvakken, de laatste versie was niet altijd duidelijk en voortgang moest handmatig worden nagevraagd. Voor een compleet projectdossier moesten documenten, statussen en communicatie telkens opnieuw bij elkaar worden gezocht.

Rollen in het portaal

Verantwoordelijke organisatie

Beheerde gebruikers, projecten, projectsjablonen en de beoordelingsflow.

Projectgebruiker

Kreeg toegang tot één of meer projecten, zag welke stukken nog nodig waren en leverde documenten aan.

Beoordelaar

Controleerde de aangeleverde stukken namens de verantwoordelijke organisatie en kon deze goed- of afkeuren.

Eindgebruiker of locatie-eigenaar

De eindgebruiker of eigenaar van de locatie waar het bodemenergiesysteem stond. Deze gegevens hoorden bij het project, maar deze partij had niet noodzakelijk een account in Yoot.

Van vraag naar product

Aan het begin lag er geen uitgewerkte productspecificatie. De eerste wensen gingen over inloggen, per project documenten uploaden, statussen tonen, herinneringen versturen en een beheeroverzicht maken. Er werd zelfs al gesproken over een betalingsproces. De opdrachtgever kende het werkproces, maar de softwarevraag was nog niet scherp. Door nieuwe gesprekken en prototypes kwamen er tijdens de stage regelmatig nieuwe eisen en wensen bij.

Samen met de opdrachtgever bracht ik losse ideeën terug tot concrete productregels en bepaalde ik welke onderdelen eerst nodig waren. Ik gebruikte user stories, wireframes, MoSCoW-prioritering en werkende prototypes om verwachtingen zichtbaar te maken en veranderende wensen te toetsen.

De eerste gedachte was WordPress. Toen duidelijk werd dat het product organisaties, gebruikers, projecten, rollen, projectsjablonen, documenten, statussen en beoordelingen zelf moest modelleren, nam ik het initiatief om Laravel, MySQL en een Nuxt-frontend voor te stellen. De technische keuzes werden in overleg gemaakt.

Tijdens de ontwikkeling kwam ook het idee op om Yoot later aan andere organisaties aan te bieden. Daardoor kon de applicatie niet hard-coded blijven rond het proces van gwbo en moest ze ruimte bieden aan organisaties met een eigen werkwijze.

Projectsjablonen

Projectsjablonen werden de kern van Yoot. Het werkproces mocht niet als één vaste lijst in de code staan, omdat organisaties hun eigen fasen, stappen en vereiste bewijsstukken moesten kunnen vastleggen.

Een organisatie kon een sjabloon vanaf nul opbouwen of vanuit een bestaand sjabloon beginnen. Binnen het sjabloon konden fasen en stappen worden toegevoegd, verplaatst en aangepast. Per stap werd vastgelegd wat er moest worden aangeleverd en wie ermee mocht werken. De wijzigingen werden tijdens het bewerken opgeslagen.

Na activering vormde het sjabloon de dossierstructuur voor nieuwe projecten. Bestaande projecten behielden de structuur waarmee ze waren gestart. Wijzigingen aan een sjabloon golden alleen voor toekomstige projecten.

Dit was technisch het lastigste deel van het product. Ik moest onderscheid maken tussen een bewerkbare procesdefinitie en de concrete projectstructuur die daaruit voortkwam. De database en implementatie zijn na de eerste stageversie verder aangescherpt, maar dat onderscheid bleef de kern.

Projectflow

Een project verbond de verantwoordelijke organisatie, de projectgebruiker, locatiegegevens, informatie over het bodemenergiesysteem en een dossierstructuur uit een projectsjabloon.

Projectgebruikers zagen per fase en stap welke documenten nodig waren. Ze konden bestanden uploaden, uploadvoortgang volgen, een upload annuleren en aangeleverde afbeeldingen en pdf’s bekijken. De status van een document bleef zichtbaar binnen het project.

Beoordelaars konden de aangeleverde stukken openen en goed- of afkeuren. Tijdens de verdere ontwikkeling na de stage is deze cyclus uitgebreid met terugkoppeling, vervangende documenten en herinneringen rond ontbrekende of opnieuw aan te leveren stukken. Zo bleef de beoordeling bij een mens, terwijl Yoot de status, volgorde en communicatie eromheen ondersteunde.

De applicatie bevatte daarnaast beheer voor organisaties, gebruikers en projecten. Voor sommige informatierijke schermen bouwde ik aparte mobiele componenten in plaats van de desktopweergave alleen smaller te maken.

Mijn bijdrage

  • Procesanalyse, user stories, prioritering en wireframes
  • Projectsjablonen en de bijbehorende productregels
  • Datamodel, migraties en seeddata
  • Laravel-API, autorisatie en documentlogica
  • Nuxt- en Vue-interface voor desktop en mobiel
  • Deployment, API-documentatie en onderhoud
  • Begeleiding van stagiaires
  • Overdracht aan mijn opvolger in maart 2023

Ik startte Yoot aan het begin van mijn stage. Ongeveer drie weken later sloot een klasgenoot aan. Hij werkte mee aan een deel van de eerste fase en stopte voor het einde van de stage. Daarna deed ik de verdere ontwikkeling en de eerste productieoplevering grotendeels zelfstandig.

Na de twintig stageweken bleef ik tot maart 2023 betaald parttime aan Yoot werken. In die periode zijn het datamodel, de interface en de functionaliteit verder aangescherpt. Later werkten stagiaires aan specifieke onderdelen van het product en begeleidde ik hen. Een van hen bouwde een aparte functie voor formuliersjablonen. Dat was een ander onderdeel dan de projectsjablonen die in deze case centraal staan.

Architectuur en reflectie

Ik koos destijds voor Laravel en MySQL aan de backend en een afzonderlijke Nuxt- en Vue-frontend. De frontend communiceerde via een REST-API met Laravel. Voor authenticatie gebruikte de applicatie Laravel Passport met bearer access tokens en refresh tokens.

De aparte Nuxt-frontend gaf mij ruimte om de interface zelfstandig op te bouwen, maar bracht voor deze applicatie ook extra complexiteit mee. De eerste productieoplevering via Plesk maakte dat zichtbaar. Ik liep onder meer tegen MySQL-toegang, CORS en hostingconfiguratie aan. Ik paste de projectstructuur aan en kreeg frontend en backend werkend online. Dat was voldoende voor de eerste livegang, maar betekende niet dat die scheiding voor Yoot de beste keuze was.

Voor een webapp als Yoot, met één eigen frontend en zonder zelfstandige externe API-consumenten, zou ik die grens nu waarschijnlijk binnen Laravel houden, de Vue-interface in dezelfde applicatie bouwen en session-based authenticatie met Sanctum gebruiken. Passport was technisch geldig, maar bracht meer OAuth-complexiteit mee dan Yoot nodig had. Een eenvoudiger opzet zou ook het inwerken, beveiligen, deployen en overdragen makkelijker hebben gemaakt.

Naast de productcode zette ik migraties, seeders, GitLab-versiebeheer, API-documentatie en een reproduceerbare database-refresh op. Dat laatste bundelde het leegmaken van caches, het opnieuw uitvoeren van migraties en het vullen van testdata in één Composer-commando.

Resultaat en grenzen

Na de eerste twintig weken ondersteunde Yoot authenticatie, projecten, locatiegegevens, dossierstappen, uploads, documentweergave, beoordeling, projectsjablonen en beheer voor organisaties en gebruikers. Niet iedere geplande workflow was toen al afgerond.

Tegen het einde van mijn periode werd Yoot gebruikt door ongeveer 25 gebruikers uit de bestaande klantenkring van de opdrachtgever. Voor hen verhuisde een deel van de documentuitwisseling uit losse e-mails naar één gedeelde projectflow. Ik koppel daar geen gemeten tijdwinst of percentages aan.

In maart 2023 droeg ik de applicatie en documentatie over aan mijn opvolger, die de verdere ontwikkeling overnam. Bij mijn laatste bevestiging in 2026 was Yoot nog steeds in gebruik.

Wat begon als centrale documentopslag groeide uit tot een configureerbare workflow met organisaties, projectsjablonen, dossierstappen, rollen en beoordeling.

  • ca. 25gebruikers uit de bestaande klantenkring van de opdrachtgever
  • 2026nog in gebruik bij mijn laatste bevestiging
  • mrt 2023overgedragen aan mijn opvolger