This portfolio was rebuilt to keep the project stories easy to maintain for the long term. The previous version used SvelteKit and Tailwind; the rewrite keeps the useful server-rendering model while replacing the framework layer with small, explicit TypeScript, HTML, CSS and JavaScript modules running on Cloudflare Workers.

The result is deliberately simple: server-rendered pages, a lightweight Hono router, responsive CSS and only the JavaScript needed for search, theme controls and small interactions. It avoids the expensive framework churn that can make a small website unexpectedly costly to revisit after a few years.

MusicalTheaterSongs.com is a specialist search platform used by musical-theatre students, teachers and institutions to find repertoire from more than 11,000 songs. Users can search by voice, range, mood, key and many other musical criteria, while administrators manage the catalogue, subscriptions and institutional access.

This is the second rewrite of the application. The previous Derby and MongoDB application had served the business for more than a decade, but its aging framework made maintenance and further development increasingly difficult. The rewrite replaces that foundation with TypeScript, Cloudflare Workers and D1, while carefully migrating the application’s data and business rules.

The new application deliberately avoids a client-side framework. Pages are rendered on the server as straightforward HTML, with only small, purposeful JavaScript enhancements where interaction is needed. This keeps the architecture explicit, fast and easier to maintain over the long term—without tying the product to another fast-moving frontend ecosystem. It also makes the application more resilient to framework churn: the core is built from durable web standards rather than a large, rapidly changing frontend stack.

Accessibility is a central part of the rewrite, not a final polish pass. The work includes semantic page structure, keyboard-friendly interactions, visible focus states, accessible forms and error messages, and automated and manual checks against WCAG guidance. A dedicated accessibility feedback form gives users a direct way to report barriers, so real-world feedback can become part of the improvement cycle.

The project remains actively developed. Alongside modern authentication, Stripe subscription flows and institutional access, the next phase will add more AI-assisted capabilities to help users explore a large, specialised repertoire more naturally and efficiently. The goal is to extend the search experience without compromising the clarity, performance and long-term maintainability established by the rewrite.

This mobile app allows motorists to give gratuities to the informal car guards that are ubiquitous in South Africa.

Car guards are individuals who provide an informal parking attendant service. They are typically dressed in high-visibility vests and assist motorists in finding parking spaces, keeping an eye on vehicles while the owner is away, and sometimes helping drivers maneuver out of tight spots. Although car guards are not officially regulated or employed by the parking facilities or retail establishments they frequent, their presence is a well-known aspect of urban life in South Africa.

This mobile application leverages modern web technologies and delivers a seamless user experience akin to native store apps. It can be installed directly onto devices and offers offline functionality, employing Progressive Web Applications (PWA) technology for caching capabilities that mitigate the dependence on an internet connection.

Upon completing a registration process within the app, car guards initiate their monitoring service by photographing vehicles enrolled in the program, identifiable through a designated sticker, which serves as verification of their oversight. They are prompted every 15 minutes with a push notification to capture successive images, ensuring continuous supervision. The guards' interface displays these photographs sequentially, arranged based on the required timing for the subsequent snapshot.

This is a large-scale software-as-a-service (SaaS) application for customer service chats. The application is designed to be efficient and cost-effective and support tens of thousands of users concurrently.

I was responsible for the entire development process of this application, from gathering requirements to writing the code. I understood the needs of the users, designed the architecture of the application, and implemented the code. I also tested the application to ensure that it worked correctly. I'm proud of this app because it showcases my coding skills and ability to build applications.
This is a chat system that allows website visitors to ask questions to human chat agents. Although artificial intelligence is improving, many organizations and visitors alike prefer human answers. Humans are better at understanding complex questions and providing nuanced answers. They are also better at building rapport and trust with customers.

This chat app was made with businesses and organizations in mind that want to provide top-notch customer service. It recognizes the importance of human interaction in resolving customer issues. It can be used in a variety of industries, including e-commerce, corporate, marketing and sales, education, nonprofits, and NGOs. The chat app is also highly optimized for outsourced customer service organizations. These organizations typically have a large customer base and manage chat operations on their behalf. The administrative side of the app is designed to make it easy to add new customers and their websites and domains.

Overall, this app is a comprehensive, user-friendly live chat solution that helps businesses provide superior customer engagement and service. It seamlessly blends technology with the irreplaceable human touch, ensuring that customer issues are resolved quickly and efficiently.

The app is fast, but speed was not the primary focus of the design. The main goal was to keep resource usage low so that pricing for users could be kept as low as possible. This is important because the app is used by a large number of people, and the cost of running the app can be significant. This low resource usage is achieved by using efficient technologies and hosting providers and by giving agents the tools to handle as many chats in the shortest time possible. In the context of this type of chat app, speed is not as important as it may seem. This is because website visitors are often slow typists, and agents are often handling dozens of chats at the same time. This means that there will always be some waiting time, regardless of how fast the app is.

This is a large-scale software-as-a-service (SaaS) application for customer service chats. The application is designed to be efficient and cost-effective and support tens of thousands of users concurrently.

I was responsible for the entire development process of this application, from gathering requirements to writing the code. I understood the needs of the users, designed the architecture of the application, and implemented the code. I also tested the application to ensure that it worked correctly. I'm proud of this app because it showcases my coding skills and ability to build applications.
This is a chat system that allows website visitors to ask questions to human chat agents. Although artificial intelligence is improving, many organizations and visitors alike prefer human answers. Humans are better at understanding complex questions and providing nuanced answers. They are also better at building rapport and trust with customers.

This chat app was made with businesses and organizations in mind that want to provide top-notch customer service. It recognizes the importance of human interaction in resolving customer issues. It can be used in a variety of industries, including e-commerce, corporate, marketing and sales, education, nonprofits, and NGOs. The chat app is also highly optimized for outsourced customer service organizations. These organizations typically have a large customer base and manage chat operations on their behalf. The administrative side of the app is designed to make it easy to add new customers and their websites and domains.

Overall, this app is a comprehensive, user-friendly live chat solution that helps businesses provide superior customer engagement and service. It seamlessly blends technology with the irreplaceable human touch, ensuring that customer issues are resolved quickly and efficiently.

The app is fast, but speed was not the primary focus of the design. The main goal was to keep resource usage low so that pricing for users could be kept as low as possible. This is important because the app is used by a large number of people, and the cost of running the app can be significant. This low resource usage is achieved by using efficient technologies and hosting providers and by giving agents the tools to handle as many chats in the shortest time possible. In the context of this type of chat app, speed is not as important as it may seem. This is because website visitors are often slow typists, and agents are often handling dozens of chats at the same time. This means that there will always be some waiting time, regardless of how fast the app is.

A small personal experiment to make indoor walks easier to measure. I started with a simple phone app for pace and distance, then removed the need to tap a lap button by building a low-cost motion-sensor trigger.

An ESP8266 board, PIR sensor and buzzer recorded each pass and sent lap times to a browser app on my phone. Later, I added a temperature and humidity sensor so I could put a walk in context. It was a useful, hands-on way to explore the connection between a physical interaction, a small service and a clear mobile interface — not an attempt to build an IoT product.

A small proof of concept to run Apollo GraphQL servers on Cloudflare workers. Copilottravel.com, a startup that is building the next generation travel search and booking engine, asked me to make a small example on how to run Apollo GraphQL servers on Cloudflare workers. For their travel search engine they need combined data from dozens of different sources. GraphQL was made for these kinds of applications.

My work gave them a handle to continue their porting efforts from Google Cloud to Cloudflare.

A simple website built in a day with Sveltekit and Tailwind running on Cloudflare's workers.

Normally I don't do very plain websites but I did this for my brother and I wanted to play around with Sveltekit and Cloudflare Workers. So while this is a simple website from an HTML prespective, there are also complicated technologies involved. It's a serverless app running on Cloudflare's edge network. This means it's infinitely scalable, super secure, very fast for visitors where it doesn't matter if you are in Alaska or Zimbabwe and - in case of Cloudflare - can be deployed with a single command. (Actually, with the latest version of Cloudflare Workers/Pages, you only need to push it to a repository like Github or Gitlab)

You can see the result at rep-it.nl. This was my first attempt to build something with Sveltekit, a new web framework with a radically different approach than most other web frameworks. Svelte is a component framework — like React or Vue — but with an important difference.

Traditional frameworks allow you to write declarative state-driven code, but there's a penalty: the browser must do extra work to convert those declarative structures into DOM operations, using techniques like that eat into your frame budget and tax the garbage collector. Sveltekit can generate different types of websites, static and server side rendered and uses adapters to tailor the result to specific deployment types like Cloudflare Workers, Node.js, Netlify, Vercel, etc.

In this case I used Cloudflare Workers. For styling I tried Tailwind, something I wanted to work with for a long time. With very little effort I got a perfect score on Google’s Lighthouse, a website performance toolkit, both on Desktop and Mobile.

This website. Built with Sveltekit and Tailwind running on Cloudflare's workers. Because LinkedIn does not offer a nice way to show a projects portfolio, I built this website. I wanted to show every page as a separate link on my profile so I needed a Server-Side-Rendered website.

I also wanted to use Serverless hosting so I don't have to pay for a full server running 24x7. Sveltekit, together with the Cloudflare adapter makes this just a deployment option without the need of any code changes.

The Tailwind CSS utility classes made it possible to not have a css file or create classes on every page. Instead you can do a sort of real-time design; keep a browser window open next to your editor and add utility classes directly on elements, like font-bold, text-gray-500 or mt-5 for a top margin.

I like to keep two browser windows open next to my editor; one for a mobile view and one for a desktop view. This way I can immediately see if I need different classes/layouts for mobile or desktop. This way of working is very efficient and a real time saver.

I came across this project on one of the freelance IT-projects websites. Because, for obvious reasons, I cannot share that much on projects I did for customers, so I decided to spend a week and build part of this app to show what I can do, how it would look like and how much I can archive in a week's time. You can see it working at crm.naguras.com. The specs document is at my Google Drive. It gave me a focused way to turn the brief into a practical, working interface before committing to a full build.

This project is a good example of how I translate business requirements in an application. After reading the specifications I still had a lot of questions but also enough to build something functional.

musicaltheatersongs.com is a web application for musicians and users in the musical and theater sector to search for musical songs based on musical-technical terms. The app is mainly used by musical students and teachers. It contains more than 11,000 songs and is used by tens of thousands of users globally. The original app was written more than 6 years ago and used a MVC framework called Derby which became obsolete. It was difficult to maintain the code or to add new functionality. I was asked to rewrite the application using a more modern toolset.

The original application had two functional parts (actually three if you count the Mongodb database as a part of the application) but was built as a single app (except for the database which is a separate service). The two functional parts are the website front-end, the part end users see and use for their searches and store their songs lists. The other part is an admin section where new songs, shows, composers and lyricists are entered and modified. It also manages user’s subscriptions, both individual and institutional (universities, etc).

I was asked to help with a Bitcoin clone (fork) called Bitcoin Euro (BTE). I installed a number of BTE nodes on virtual servers and set up the necessary infrastructure around it like a blockchain explorer, a mining pool and a wallet. For this I adapted a few Open Source projects to work with BTE instead of Bitcoin. I’m not really a blockchain expert but I do have a reasonably good insight in how blockchains work. I did make some small changes to the Bitcoin source code (made with c++). The explorer, mining pool and wallet software were all built with Javascript technologies and node.js.

The Cloud Trade Copier is a cloud based Binary Options Trading System system where Signal Providers send signals to the service using a web based interface. When a signal arrives, all the subscribers to that signal are gathered from a Redis in-memory key-value store. Per user we check which broker they use and send the signal to other microservices (one or more per broker) that will send the purchase transaction to the broker's server.

This is a Desktop app for Windows and Mac that can trade Binary Options based on signals from a Signal Provider. The signal provider uses a simple app as pictured below to signal a trade opportunity. Because the binary options trade is a very fast moving business where a single second can mean the difference between a losing or winning trade, the interface has to be really simple so with just a single click the trader (the person generating the signal) can send out the signal.

The end-users who subscribe to one or more signal providers use another Desktop app for Windows or Macintosh to trade the signals the provider sends out. The Binary Option Brokers do not give API access to their trading systems. So I built an app that will open a broker’s website and inject some Javascript code in the webpage to be able to control the website and execute trades.

A shrink wrapped Windows Desktop program for bookkeeping created for the Dutch market. I did the design, architecture and programming of this app. At it's time it was a refreshing new approach to accounting and got thousands of users. The goal was to make it as easy as possible for non specialists to keep their books up-to-date.