From scattered emails to a configurable project workflow

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.

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 expanded the product vision almost every week.

My work was therefore not limited to implementation. I had to work with the client to determine what the system should become, turn loosely connected ideas into product rules and decide 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. The application grew from a document solution into a full-stack product.

During development, there was also an ambition to offer Yoot to other organisations. Supporting that ambition meant the product could not remain hard-coded around gwbo’s process and needed room for 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

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. Junior developers 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.

My responsibility covered the path from client discovery to technical delivery.

• 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
• Mentoring junior developers
• Handover to my successor in March 2023

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.

That architecture matched the growing ambition of the product and gave me room to develop the interface independently. It also introduced more complexity than this first-party portal needed. The first production release through Plesk exposed that cost. I encountered MySQL access, CORS and hosting-configuration issues. I adjusted the project structure and got both runtimes online, but that was a pragmatic way to achieve the first release, not proof that the original boundary was ideal.

I would make the boundary simpler today. For a first-party web product without independent external API consumers, I would probably keep the product within Laravel, build the Vue interface in the same application and use session-based authentication through Sanctum. Passport was technically valid, but it introduced more OAuth surface than Yoot required. A simpler boundary 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, there was already a working product foundation with authentication, projects, location data, workflow steps, uploads, document viewing, review, project templates and administration for organisations and users. Not every planned workflow was complete at that point. The paid work that followed turned the internship version into a more developed product.

By the end of my time on Yoot, approximately 23 to 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. What matters is that Yoot Portaal was used in practice and developed over several years.

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.