Context
gwbo advised architects, property developers and contractors on energy-efficient residential and commercial construction, including ground-source energy systems. In the Netherlands, specific work on these systems is governed by recognition requirements and quality schemes. Around the start of Yoot, the relevant schemes were updated in part to improve information exchange between the recognised companies involved.
Yoot supported the project administration around that work. It did not certify anyone or decide whether a document met legal requirements. Technical review and responsibility remained with the specialists and responsible organisations within the process.
Existing clients submitted most project evidence by email. Attachments were spread across inboxes, the latest version was not always clear and progress had to be chased manually. Completing a project record meant repeatedly bringing documents, statuses and conversations back together.
Roles in the portal
Responsible organisation
Managed users, projects, project templates and the review workflow.
Project user
Received access to one or more projects, saw which evidence was still required and submitted documents.
Reviewer
Checked submitted material on behalf of the responsible organisation and could approve or reject it.
End user or site owner
The end user or owner of the site where the ground-source energy system was located. This information belonged to the project, but the party did not necessarily have a Yoot account.
From question to product
There was no complete product specification at the start. The first requirements covered sign-in, uploading documents per project, statuses, reminder emails and an administration overview. There was even early discussion of a payment flow. The client understood the work process, but the software product had not yet been defined. New conversations and prototypes regularly surfaced additional requirements during the internship.
With the client, I turned loosely connected ideas into product rules and decided which capabilities were needed first. I used user stories, wireframes, MoSCoW prioritisation and working prototypes to make expectations visible and test changing requirements.
WordPress was the initial direction. Once it became clear that the product needed to model organisations, users, projects, roles, project templates, documents, statuses and reviews, I took the initiative to propose Laravel, MySQL and a Nuxt frontend. The technical choices were made in discussion with the people involved.
During development, the idea also emerged of offering Yoot to other organisations. That meant the application could not remain hard-coded around gwbo’s process and had to support organisations with different ways of working.
Project templates
Project templates became the core of Yoot. The process could not be implemented as one fixed list because organisations needed to define their own phases, steps and required evidence.
An organisation could build a template from scratch or start from an existing one. Phases and steps could be added, reordered and edited. Each step described what needed to be submitted and who could work with it. Changes were saved while the template was being edited.
Once activated, the template provided the project record structure for new projects. Existing projects kept the structure they started with. Template changes applied only to future projects.
This was the most difficult technical part of the product. I had to distinguish between an editable process definition and the concrete project structure created from it. The database and implementation were refined after the first internship version, but that distinction remained central.
Project workflow
A project connected the responsible organisation, the project user, site information, ground-source energy system details and a record structure created from a project template.
Project users could see which documents were required for each phase and step. They could upload files, track upload progress, cancel an upload and open submitted images and PDFs. Document status remained visible within the project.
Reviewers could open the submitted evidence and approve or reject it. During the paid development period after the internship, the cycle was extended with feedback, replacement documents and reminders for missing material or documents that needed to be resubmitted. Review remained a human decision while Yoot managed the surrounding status, order and communication.
The application also included administration for organisations, users and projects. For some information-dense screens, I built dedicated mobile components instead of simply compressing the desktop layout.
My contribution
- Process analysis, user stories, prioritisation and wireframes
- Project templates and their product rules
- Data modelling, migrations and seed data
- Laravel API, authorisation and document logic
- Nuxt and Vue interfaces for desktop and mobile
- Deployment, API documentation and maintenance
- Guiding software-development interns
- Handover to my successor in March 2023
I started Yoot at the beginning of my internship. A classmate joined about three weeks later, worked on part of the initial phase and left before the end of the internship. I then handled the continued development and the first production release largely independently.
After the twenty-week internship, I stayed on in a paid part-time role through March 2023. During that period, the data model, interface and feature set were refined further. Software-development interns later worked on specific parts of the product, and I guided them. One of them built a separate form-template feature. That was distinct from the project-template model at the centre of this case.
Architecture and reflection
I chose Laravel and MySQL for the backend and a separate frontend built with Nuxt and Vue. The frontend communicated with Laravel through a REST API. Authentication used Laravel Passport with bearer access tokens and refresh tokens.
The separate Nuxt frontend gave me room to develop the interface independently, but it also introduced additional complexity for this application. The first production release through Plesk made that visible. I encountered MySQL access, CORS and hosting-configuration issues. I adjusted the project structure and got the frontend and backend running online. That was enough for the first release, but did not mean the separation was the best fit for Yoot.
For a web app like Yoot, with a single first-party frontend and no independent external API consumers, I would now probably keep that boundary inside Laravel, build the Vue interface in the same application and use session-based authentication with Sanctum. Passport was technically valid, but introduced more OAuth complexity than Yoot needed. A simpler setup would also have made onboarding, security, deployment and handover easier.
Alongside the product code, I set up migrations, seeders, version control with GitLab, API documentation and a repeatable database refresh. The refresh combined cache clearing, migrations and seeded test data in a single Composer command.
Outcome and limits
After the first twenty weeks, Yoot supported authentication, projects, site data, workflow steps, uploads, document viewing, review, project templates and administration for organisations and users. Not every planned workflow was complete at that point.
By the end of my time on Yoot, about 25 users from the client’s existing customer base were using it. For them, part of the document exchange moved from individual email threads into one shared project workflow. I do not attach measured time savings or percentages to that outcome.
In March 2023, I handed the application and documentation over to my successor, who took over further development. At my most recent confirmation in 2026, Yoot was still in use.