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. Nieuwe gesprekken en prototypes maakten het beoogde product bijna iedere week ambitieuzer.
Mijn werk bestond daarom niet alleen uit implementeren. Ik moest samen met de opdrachtgever ontdekken wat het systeem precies moest worden, losse ideeën terugbrengen tot concrete productregels en bepalen 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. De applicatie groeide daarmee van een documentoplossing naar een echt full-stack product.
Tijdens de ontwikkeling ontstond ook de ambitie om Yoot later aan andere organisaties aan te bieden. Om die ambitie mogelijk te maken, moest het product niet alleen het proces van gwbo ondersteunen, maar ook 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
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 junior developers 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.
Mijn verantwoordelijkheid liep van het uitwerken van de klantvraag tot de technische realisatie.
- 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 junior developers
- Overdracht aan mijn opvolger in maart 2023
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.
Die architectuur paste bij de groeiende productambitie en gaf mij ruimte om de interface zelfstandig op te bouwen. Tegelijk bracht de grens meer complexiteit mee dan voor dit first-party portaal nodig was. De eerste productieoplevering via Plesk legde dat bloot. Ik liep onder meer tegen MySQL-toegang, CORS en hostingconfiguratie aan. Ik heb de projectstructuur aangepast en beide runtimes werkend online gekregen, maar dat was een pragmatische manier om de eerste livegang te realiseren, geen bewijs dat de oorspronkelijke grens ideaal was.
Ik zou dit tegenwoordig eenvoudiger opzetten. Voor een first-party webproduct zonder zelfstandige externe API-consumenten zou ik de productgrens waarschijnlijk binnen Laravel houden, de Vue-interface in dezelfde applicatie bouwen en session-based authenticatie met Sanctum gebruiken. Passport was technisch geldig, maar bood meer OAuth-oppervlak dan Yoot nodig had. Een eenvoudiger grens 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 stond er al een werkende productfundering met authenticatie, projecten, locatiegegevens, dossierstappen, uploads, documentweergave, beoordeling, projectsjablonen en beheer voor organisaties en gebruikers. Niet iedere geplande workflow was toen al afgerond. Het betaalde vervolgwerk maakte van die stageversie een verder uitgewerkt product.
Tegen het einde van mijn periode werd Yoot gebruikt door ongeveer 23 tot 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. Voor mij zit de waarde in het daadwerkelijke gebruik en de jarenlange doorontwikkeling.
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.