Projects

Lightweight, native Mac menu bar app that helps you manage multiple PHP installations, locate config files and more. Also interacts with Laravel Valet. Originally started as a utility app in 2019, but became popular in 2021 and later when the project garnered international attention and support.

In 2023, the project achieved a milestone of 3000 stars on GitHub. In 2024, the project was more or less finalized, but I continue to work on the project every now and then.

While other projects like Laravel Herd have caught on since the tool’s inception and growth has definitely slowed, PHP Monitor remains supported, open source and free for everyone to use, since there’s still lots of people using Laravel Valet.

I also have plenty of blog posts dedicated to the development of PHP Monitor and its many releases, take a look at the archives for more information.

This is a package that helps you build a self-updater for a given macOS application. It is supposed to act as an alternative to Sparkle.

This was originally written as part of my “zero non first-party dependencies” policy for PHP Monitor, where the original code has been responsible for serving updates for many users over the last few years.

This package contains code that can be used to ship a self-updater app that you can ship alongside your app, with code that you can use in your main app.

Your app must ship the self-updater as a separate sub-app, so that it can be launched independently from the main executable, which is terminated upon launching the sub-app.

A PHP package that leverages ffprobe and ffmpeg to extract info and cover images from MP3s or other media files.

Currently in use for my own static podcast feed generator at xpgains.net. It is used there to extract all relevant information from the MP3 files and generate a working RSS feed that is compatible with iTunes and other podcast aggregators.

A PHP package that helps you generate simple placeholder images with a specific size, color, and some text on them.

Docker image (<250 MB) for PHP 8.3, using the Alpine image as a base. Used for my own test runners.

I started making these runners in 2020 with PHP 8.0, and have separate runners for each PHP version since.

(The linked URL is the latest as of listing this project here.)

For DIVE, I also maintained slightly altered versions with more dependencies, most of which are additional dependencies for our own projects. You can find those here, for example. For DIVE I maintained these starting with PHP 7.4.

A package for a dynamic back-end with little configuration for Laravel that can be extended if necessary. By registering a given model, you can very easily get access to simple CRUD operations.

Atlas currently serves as the CMS for a variety of sites that I run, including this very website. It has received updates every year, but remains closed source code, at least for now. I do plan on open sourcing this eventually.

This package is intended to be used for quickly generating placeholder images with a specific size, color and text.

Uses the PHP GD extension to accomplish this, and you can also bring your own TrueType fonts. A very simple package, but basic enough for various purposes.

iRail.be is a web-application that uses data from http://api.irail.be to create a hyper-media driven application for the Belgian railway company. The source code for the API is also public but the API was not built by me.

The majority of the website’s code was written during my internship for iRail prior to working for Underlined, and during subsequent editions of oSoc (open summer of code) other students have made improvements to my existing code.

You can visit iRail today and use it to plan your trip.

The Device Configurator app originally started as a standalone native app, but eventually made it into one of the individual marketing apps for a medical device company.

This app gave the user a drag-and-drop system that would let users organize and configure their multi-device setup, with the option to preview various configurations in AR.

The configurator component was actually a separate library, as well as a separate app (which was very minimal). It was definitely one of the coolest projects I’ve ever worked on since it dealt with multi-layered 2D components, connection points, etc. which required very precise and intuitive controls.

I was responsible for the entirety of this project, from prototyping to delivering the eventual final product.

For DIVE, I maintained a plethora of marketing apps for a company that manufactures medical equipment. I managed various internal Enterprise applications that they used for marketing purposes, and at the center of each app was this foundational framework.

This originally started as a single application that required maintenance, but once the company approached us for additional apps, it seemed apparent that there was going to be need to be some sort of shared codebase.

This framework contains all shared functionality, including functionality responsible for custom navigation, custom transitions, state management (including restoration), custom video playback components, and so much more. This also included, for example, an integrated document library feature, with versioned “document bundles” which were periodically updated via an external server, for which I wrote the adapter and set up a push server myself.

Anything that wasn’t a discrete feature as part of any specific app ended up in this shared framework, and it went throughout several major versions before the apps stopped being under active development in early 2024. I consider this framework to be a major reason why many of the apps worked as well as they did, and why our client kept coming back until the main driving force behind the entire marketing app suite left the company, and the project was eventually sidelined after 5 years.

I was responsible for the entirety of this project, and all marketing apps, as well as spin-offs. I’m very proud of this project in particular, as it was a tremendous effort given that I was the only developer working on it all.

In 2019 it was a major privilege to be tasked to work with the rest of the folks at DIVE on the new website of De Warmste Week, Belgium’s biggest charity fund-raising week.

Each year, charities can register a few months before the event itself, and then those charities can raise money via the platform. During the event itself, people can request songs to be played via text message, and donate that way, as well. As such, donations had to go through the website and there was a lot of traffic that the site needed to be able to handle.

I was responsible for various features, like: project search, event registration, charity pages, certain features in the back-end, legacy organisation import, and more. (As a team we were tasked to work on pretty much the entire project’s features, so no one had particular ownership of any given feature.)

This was a significant and notable project, and we maintained it that year and subsequent years until 2023, when we handed over the code to another team at the public broadcasting company.

I have worked on a massive platform for the same company that makes wallcovering products over the last few years.

This is the project that has probably persisted at DIVE the longest, since I believe we started work on the legacy site in 2016, when DIVE was still Underlined.

(Back then, we also worked on the Wallcovering Media Library project for this particular client: my contributions are listed below.)

Since working on the media library API, I helped work on a legacy site that was handed over to us at the time. This site was a true legacy project: it was still based on PHP 5.6, and it still had some Flash components, many years after it was dropped from most browsers. (At the time, PHP 7.2 was the recent version of PHP, I believe.)

We supported this for an extended period of time before replacing this with a new platform. This platform (which began life as a PHP 7 project and now runs on PHP 8.3) consists of multiple parts, including:

• The company’s new website ended up being a massive undertaking. I contributed various pages and features to make that site a reality. (I also helped work on various features, including, for example, a custom search component with faceted search, a feature that was eventually refactored and repackaged into the B2B platform too.)
• A large aspect of this project is also a Laravel Nova back-end, to which I made various contributions as well. This also meant building custom Laravel Nova components and fields for certain features that were not supported out of the box.
• I also worked a fair bit on the B2B platform. Most key parts of this B2B platform and the main site were primarily architected by our technology lead, who made excellent architectural decisions that made maintaining these interconnected projects a bit easier than it would regularly be. I consider my contributions to the B2B platform and other integrations to be minor compared to his work.

There’s even more components to this platform like a shared authentication layer and such, but my contributions have been far and few between for those components. While I had to make minor adjustments from time to time, I was certainly not responsible for building that part of the platform.

Since I worked on multiple Swift projects from time to time over the years until those eventually dried up, I also periodically worked on a variety of the sites mentioned above, although mostly fixing minor issues or implementing minor features after 2022, since this project was primarily owned by our tech lead.

By 2024, while my colleagues continued to work on the B2B website for the company, I was responsible for the majority of the back-end work for a spin-off website for the same company. Work on these projects continues to this day, although I should be leaving DIVE at the end of the year, so this is likely my final project at the company.

In 2022, I built and maintained a bridge API that interfaces with a SOAP-powered system for a medical device company. Their assets were managed via a third-party platform, but those assets needed to be available in their marketing apps.

To make this possible, I built a custom bridge API which periodically pinged the platform and built up-to-date packages for the marketing apps.

I eventually added push notification support to this bridge API as well, so that individual apps and devices could register for push notifications once packages receive updates.

From 2018 until late 2023 we built and maintained the Craft-based website for a Belgian company that sells all sorts of light bulbs and such.

I was responsible for taking care of various API integrations, and fixing a few bugs on the front-end – but my most important work was done on the API, which remains Laravel-based and fast (Craft was not a good basis for the API given its speed).

In 2024 a new version of the site was launched. This new website no longer uses Craft and now uses Statamic. The same API that I helped work on is still in use for this new version as well.

In 2018 work started on a very complicated project: ImpactWizard, a platform to track a project’s impact. This website we needed to build turned out to be super challenging, because it was supposed to guide users through a complex flow of questions that was supposed to help you come to certain conclusions.

To make this possible, I had to design and build 5 custom modules with lots of front-end work that was required to make the project work. In addition to that, I also had to implement a custom survey feature so that customers of ImpactWizard could create surveys and view responses.

The latter was an integration with TypeForm, but I had to replicate the majority of TypeForm functionality in the back-end of ImpactWizard, which was quite the effort.

Once the project was set up and ready, I had to build support for whitelabel versions, which would also connect in some ways to the main installation of ImpactWizard. This entire system was quite challenging to build!

I continued working on the project (and whitelabel variants) until 2021, after which the project was eventually shut down.

I was responsible for the majority of the development during the lifetime of this project, with the exception for the first few weeks, when we worked together to come up with an initial design (done by a colleague) and database schema.

From 2017 until 2021 we worked on apps for a company responsible for a large soccer platform, for both iOS and Android.

The Android app was handled by a colleague and I was responsible for the majority of the work on the iOS app after some initial work was done by a colleague.

This was a very challenging project due to the number of features and also because we were only responsible for the client, and the API was managed by the folks at the company.

The project started as a fairly simple “viewer” application, but later required various rewrites to support signing in with different multiple accounts.

We had to implement the following features in the app:

• Multi-user support (added later in a major version update)
• Direct messaging and real-time chat
• An email system w/ various inboxes and a UI like Gmail’s
• A calendar feature with check-ins
• Surveys and questionnaires
• A way to view all played matches
• Video playback via a custom video player
• Integrating with Firebase analytics
• Integrating with Crashlytics
• Offline functionality where possible

Certain features were also restricted, so much of the app was locked behind a variety of flags which were toggled on a per-club basis. We also had a robust migration system which allowed us to release features fairly quickly.

Notably, user switching turned out to be a big stumbling block for stability, especially because the API was a bit finnicky and token expiration tended to be inconsistent.

For the majority of the project (basically after the first two weeks), I ended up as the sole developer of the iOS app (for both iPhone and iPad) and I built all of the features.

I was also responsible for tracking down and fixing all the bugs, as well as deploying updates to the App Store.

Eventually, the app was crash-free for ~99% of all users, which was notable given the API and the scope of the features and how the app was maintained by only me.

At some point a major redesign for this app was planned, and a different company with a larger team was chosen to take over ownership of the project, so features could be rolled out at a faster pace.

For a car company we maintained an application similar to the Wallcovering Media Library project. Once again, we used Algolia for search indexing, Amazon S3 as a storage service, and I built a custom API for this project.

I was responsible for the API only, but I did come into contact with the client-side application when I needed to test features.

In 2017 we started work on the website for the Belgian Hematology Society. This was an OctoberCMS website that allowed administrators to properly manage their complex website.

I helped build the custom submodules for the theme and a custom plugin which enabled a bunch of custom functionality that was not built into OctoberCMS. This functionality allowed for the management of pretty much all of the content on the website in a very user-friendly fashion.

This way, the admins could manage: clinical trial information, committee members, drug data listings, events, galleries, hematology centers, magazine issues, members, news items, and much more. All of these different types of data each had models and their own section in the back-end.

It is my understanding that this project is still maintained at DIVE from time to time, but all of the functionality was effectively finalized by 2021. The majority of the back-end work was done by me, and the front-end work by a colleague. I really dig the design of the website, and I think it has held up well.

(Because I want this entry to reflect the project that I helped deliver, I have linked the archived version of the website.)

Ginto was an iOS application that let you keep track of your favorite gins and tonics.

At Underlined we maintained a large database of various gins and tonics, along with their recipes. I helped build the iOS application and the back-end that drove the app, and allowed volunteers to upload information about said gins and tonics.

One of my favorite bits was the “bottle cropper” component in the back-end, which guaranteed a uniform appearance for each bottle displayed in the app, which was a nice touch.

I helped build the majority of the API, back-end and a good chunk of the main iOS app. The Android app was maintained by the owner of YungPanda, Michael, with whom we collaborated on Ginto. He also had a hand in shaping the direction of the API.

It was a project that we all loved working on. Unfortunately, it was more of a passion project, which also led to the eventual decision to terminate the project, as integrating a store component was proving to be too costly with little ROI.

In 2015 we built an application in cooperation with Mono to learn the Japanese hiragana and katakana alphabets.

The app also acts as a reference application for all hiragana and katakana characters. Use it to quickly look up the right characters, or train your knowledge using the quiz feature.

The app was last updated in 2019, but remains completely functional as it was written with Objective-C at the time, so it hasn’t needed many updates over the years.

In 2017 we were given a design by a medical company that focuses on heart health to reproduce and built a website with OctoberCMS based on this design.

We also built an advanced back-end which consisted of several plugins, which included plugins for: the main theme, custom settings, careers management (for job openings), custom forms, a component to manage FAQ entries, manage prescription plans, and more. I helped build and maintain all these plugins and the theme.

Starting in 2016 I worked on an application for a carpet company, which was installed on large Android tablets on various in-store locations. This then allowed users to explore the various carpet collections which were made available via a dedicated back-end.

This in particular was a special application, because we needed to build a bunch of custom functionality that didn’t exist at the time for Cordova applications:

• An offline update system. Not all of the tablets were connected to the internet, so I had to build a feature that could read from USB drives in order to perform catalog updates this way. This was challenging, because certain “catalog updates” also required app updates. USB 2.0 ports are also fairly slow, so the transfer of the multi-gigabyte catalog updates could take a while.

• For optimal performance, I also helped build an SQLite bridge for Cordova, which we exclusively used for this project. Back in 2016, what you could do with in-browser databases was very limited. Initially we just used large JSON blobs from which we read data, but our search functionality became very costly and slow, especially because the tablets in question ran an older version of Android and very slow processors. In order to avoid this issue, the SQLite bridge improved performance for certain complex search queries by 100x.

I ended up working on both of these custom features, as well as the general functionality of the Cordova app.

After this challenging project, we decided internally to walk away from Cordova since the overhead of the browser on slower devices was deemed too high. Despite that, I really enjoyed working on this project, also because we had custom hardware at our office to test and distribute these updated builds and catalog packages.

In 2016 I built a simple WinForms application for a local university, which was built for them to manage internal contact information.

A regular ERP or special contact management app was too complicated for their basic use case, so we built a simple app that did just what they needed. This was a fast and nice application.

This is the only .NET application we ever developed, and this happened mostly because I was fairly familiar at the time with WinForms apps and C#.

Our usual bread and butter were web (PHP) and native (iOS) projects, so this was a bit of an outlier. Nonetheless, a fun project.

In 2016, we built and maintained the website for Startups.be. This was one of our first OctoberCMS projects, which were very user friendly at the time.

The most interesting part of this project was the huge list of startups and blog posts related to said startups, which was made to be easily searchable by using Algolia as a search back-end.

We maintained the site for a few years until startups.be eventually became scaleups.be.

In 2016 we were tasked with a minor refresh of the app of arguably Belgium’s most famous TV show. (The show has been a staple in Flanders since the early 90’s and it’s about a Flemish football club and friends.)

This was an application that would let people watch said TV show on demand. The app was originally launched several years prior but now needed to be updated.

The existing app was outdated and needed to be updated for iOS 9 and iOS 10 at the time, for both iPhone and iPad.

The app was eventually scrapped in favor of newer online platforms (such as Streamz and the public broadcasting service’s own streaming service), but it was part of the digital strategy of the Flemish public broadcast service for some time.

I was responsible for the majority of the the various upgrades and changes to how video was served, as well as deploying these updates via the App Store.

For a company that makes wall coverings we built an app that would allow customers to bulk download high-resolution assets on demand.

For this application, I built the API (with Laravel) and built a “zipper service” which would aggregate and zip files and email the person who requested the download.

To make this possible, the following components were necessary:

• A front-end (written by a colleague!)
• A back-end (for the company to manage which assets are available)
• An API (for the front/back-end to be able to work)
• A Lambda function (to resize images and generate thumbnails automatically)
• A zipper service (running on EC2, which sent data to Amazon S3)

When a download was ready, a message was also sent via Pusher to the website. For smaller downloads, one could usually download assets within a couple of seconds. For larger downloads, it might take a couple of minutes.

I was responsible for a lot of the work on the API and integrating with other components that eventually notified Pusher. I also wrote some code to clean up generated “zipped” files that had expired, and helped us track if everything still worked correctly.

In 2016, we built a Drupal integration that allowed a company to have a clear overview of all reservations for all of their conference rooms.

They used Planyo for this service, so we had to integrate with their API and present a simple UI that worked across various timezones.

This project consisted of two parts:

• The Drupal module, which could be installed. This module was responsible for displaying which different conference rooms were still available.
• Our own API shim, which did some caching and prevented API calls to Planyo from occurring under certain circumstances. Instead of directly calling the Planyo API, the Drupal module interacted with this API, which, in turn, communicated with Planyo when needed.

This application is a webapp that was also published on mobile platforms with Cordova. It allowed users to preview the effects of the various different insulation materials on sale by the company that we worked for via a simple interface.

This allowed users to check what a given audio file would sound like with and without insulation material in between two rooms.

There were two parts to this application:

• One part was the back-end, which was a module for Drupal. This module also exposed an API that the Cordova app consumed. This was written in PHP, like Drupal, but the module itself used a few Laravel components. For performance reasons, Illuminate\Database was used instead of Drupal’s native database integration and modeling, although native Drupal functionality was used to manage permissions and the like. Administrators could upload new configurations for different insulation materials for different markets, and those would then become visible on a per-country basis inside the app.

• The other part was a Cordova app, which allowed us to produce iOS and Android versions of the webapp. This effectively meant we distributed three versions of the app. This was challenging at times, especially when iOS updates were released.

While this started as an Underlined project, this app received multiple updates over the years, and the web version remains supported to this day, almost ten years later, at DIVE. I worked on this particular app and API from 2015 to 2019, even upgrading the entire module to a newer version of Drupal, which was quite the undertaking.

Due to extensive documentation about how to set up and build the web version, this project is now maintained by other members of the team.

From 2015 until 2019 I worked on the Wordpress website for Circuscentrum, for Underlined.

This was an existing Underlined project from before I joined as the first employee, but whenever visual or content updates were necessary I updated the custom Wordpress modules we built to better facilitate the website.

From 2015 until 2019 I helped work on the website for Monokrom, a type foundry from Oslo, Norway. This was an existing Underlined project that I supported.

As this was a custom project built on CodeIgniter, this was a little bit of a new experience at the time, as I only had experience with Laravel, Symfony and some other minor frameworks (Slim was fairly popular in 2014, too).

I believe the current iteration of the website is currently the same as the one that was originally built almost ten years ago, so I have linked the most recent version.

You can also check this snapshot to see what the site looked like in 2019, when the last major changes were made.

In 2015 we built the first iOS and OS X version for a company who make a private photo gallery and syncing app. This was an Underlined project, and I worked primarily on the iOS version, with my colleague working primarily on the OS X version.

The most difficult component to build on iOS was a month view for the picture gallery, with various integrations and the ability to share images. This was one of the last projects we did with Objective-C before switching to Swift.

Our version of the app is no longer available, as it has been superseded by a newer version, which, to my recollection, is now built in-house.

From 2015-2017 I worked on a simple Cordova application for veterinarians, which would allow them to keep clients up-to-date about the status of their pets.

In addition to the Cordova application, I also maintained the Laravel-based API as well, which drove most of the interactions with the app. (The app was also accessible via the web, as was usually the case with the web apps we made.)

In 2015 we were contracted to work on an iOS app to help you track your pregnancy and development of your young child. It’s supposed to give you tips and let you save notes and pictures as your kid grows.

This project came to us as the project needed some serious updates for a more recent version of iOS, so we took care of that in 2015.

In 2017 and 2018 the app needed additional updates to support newer devices and fix layout issues, so we came back to the app at that time as well, and made many significant changes and improvements.

I worked on the majority of the updates and changes for this project, but it’s fair to point out that this started as a legacy project in the first place.