Software and Web Development

Current Work

Backend / full-stack developer · 14 Oranges Software · 2022–present

I work on InfoGrove, a platform that powers mobile apps for cities, municipalities, and organizations across North America. My primary responsibility is the API backend and database, alongside the web-based CMS used by customers to manage their apps.

Core stack: PHP, Laravel, MongoDB, Vue, Node.js/Express, Linux

What I Ship

• Backend and CMS implementations for new product features, designed in collaboration with mobile developers.
• A migration of the product’s primary data layer from MySQL to MongoDB.
• A TOTP-based two-factor authentication system implemented for the platform’s requirements.
• Application and infrastructure changes needed to run reliably across multiple servers, including load balancing.
• Architecture and dependency improvements that reduce maintenance work and make Laravel upgrades easier.
• Requirements, tooling, deployment support, and production troubleshooting where the work crosses role boundaries.

When I joined, CEO Sylvain Marcotte wrote a short profile of my career shift.

Selected Projects

InfoGrove Platform Work

InfoGrove is a long-lived product rather than a greenfield demo. Changes have to preserve existing customer data and behaviour while supporting new mobile and CMS features. My role spans implementation, data modelling, API design, maintenance, deployment, and collaboration with the developers consuming those APIs.

ChurchWeb

Before software became my profession, I built a service-planning and volunteer-scheduling platform because repetitive administration was taking time away from the people I was there to serve. ChurchWeb became the largest application I had built at the time and remained in production at King Road Church for ten years — more than six years after I left.

Broadcast Tally System

When a venue needed camera tally but a commercial system was not practical, I built a Node/Express service that communicated with the broadcast switcher, distributed state through MQTT and Socket.IO, and drove both browser-based indicators and physical ESP32 lights.

The server and ESP32 firmware are public on GitHub. The software and hardware demos are linked below, with more context on the Electronics page.

Working with AI

I use agentic tools to explore code, draft bounded changes, and assist with maintenance and troubleshooting. Generated work still receives the same review as any other contribution: I check it against the surrounding architecture, simplify it, and verify the behaviour before it ships.

The value depends on the shape of the problem. A contained library migration can arrive nearly ready to use; subtle editor behaviour once produced a technically working 300-line change where a 30-line solution was appropriate. Knowing when to accept, revise, or discard the draft is part of the engineering work.

How I got into Programming

Programming was a consistent hobby for me long before it became a job. Whenever something needed automating, I built a software tool - and sometimes it included hardware, too.

The Beginnings

My first exposure to programming dates back to my pre-teens. My dad, a medical doctor, had decided to take advantage of a computer to help with administrative tasks at his practice. As a first step towards that he got himself an Atari ST for home use. The Atari ran a Basic interpreter called Omicron Basic, with which he started to program. I recall him showing me how to program a simple game where a player would attempt to guess a number in as few steps as possible. This fascinated me and I got hooked.

Soon I got my own Atari, and then another one. I had heard of networking - computers talking to each other - and wanted to do that with the two machines I had. I ended up networking them via their built-in MIDI interfaces. Yes, MIDI was built for music but you could send anything over a MIDI cable and so I extended the numbers game and other experiments to multi-player versions.

Eventually I got my first PC. With my uncle’s help I built it from parts (I still remember the specs: Intel Pentium 90, 16 MB RAM, 1.6 GB HDD, a 14” XGA CRT monitor). Soon, we got internet access via dialup and a modem card was added to the PC, then a network card (10MBit BNC/coax), and more PCs came to our home (I have 3 younger siblings).

Networks and the Web

At school, I was taking a computer science class taught by Juergen Bremer who I credit for laying the foundation of my ongoing interest in and knowledge of anything to do with modern networking and the internet. The class also expanded my very rudimentary programming skills; the language we used there was Pascal on MS-DOS.

The internet (and Windows, with the Netscape Navigator browser) quickly became more commonplace, and Mr. Bremer taught HTML. It was version 4 at the time - before there was CSS, when JavaScript was a hell of a mess (btw typeof null still equals "object" today), and my initial dabbling with web development didn’t yield any useful fruit apart from static websites. However, I soon started playing with Perl/CGI and then PHP (which, like JavaScript, was messier then than it is now), fascinated by its ability to make websites dynamic and behave like compiled programs in some ways.

At that time the computer room at school had a Novell NetWare 4.x file and print server. I snuck a copy of a license key to try it at home and for some time my family shared files and printers with NetWare at home. Then Mr. Bremer began to experiment with Linux and along with some other students I started to hang out with him after school, to learn how to install and configure a Linux server and how to run Samba (free file and printer sharing replacing NetWare) and share an internet connection (masquerading and routing with iptables). Of course this knowledge was quickly applied at home as well and our home became one of the first to have a Linux server that provided internet access and other services to each computer in the building.

At some point, chatrooms on websites and messaging services with native clients such as ICQ came out. I wanted to implement something like that myself and ended up writing WeberTalk, a chat program with a Windows backend and Windows client (all written in Borland Delphi) that I hosted on our home Linux server after figuring out DDNS and port forwarding. For several years my siblings, cousins, and some friends used WeberTalk to communicate. A friend from high school, Daniel Rikowski, even wrote his own client for it.

Solving Problems with Software

After high school I took computer science classes at Dortmund University, but ended up committing to church ministry work (music) instead of pursuing a career in software at that time. However, over the years I continued to write software, often to solve a problem at hand:

As a piano teacher I needed a way to leave notes and a weekly practice evaluation for my students after each lesson and came up with a web app to support that.

As a worship pastor I had a host of repetitive administrative tasks related to service planning, volunteer scheduling, rehearsal logistics and more, which took valuable time away from the work I was getting paid for and could be automated, so I wrote a platform called ChurchWeb which became the biggest app I had worked on to date - and one that ended up being deployed at King Road Church in Abbotsford for no less than 10 years, including more than 6 years after my departure.

Other projects included a UI for nursery volunteers to broadcast a call number to screens in the auditorium, a reference time system for use throughout the building, a broadcast tally system, a power sequencer to turn devices on and off in the right order and a web UI to control projectors. Some of these also included hardware (see Electronics for more).