A big chunk of what I worked on over the years was under white label. Some projects could be too small or insignificant, I don't mention servers I manage for clients, for example. The list could also be outdated. Therefore this is far from being an exhaustive list. More like a wall of honourable mentions

The list is quite technical and was written with the assumption that the reader has some coding knowledge. If you don't have coding knowledge, feel free to skim the technobabble!

Most of the open source projects are old (when I was starting out). Therefore some of the code doesn't represent my current style or the level of quality. Nevertheless they collectively helped sharpen my skills and help showcase the broad range of problems I worked on over the years.

The more recent projects (in no particular order) are the web development projects.

The games and tools were done between college and 2013.

Web development

MyVibe is a platform I created for a client where user can accomplish various tasks like play some games and fill some surveys to gain Bam coins they can exchange for gifts and prizes. There is also an Instagram like section with an infinite-scroll feed of videos and photos posted by the users.

The platform is built on rails/stimulus. With a turbolinks ios app.


I created a few intranets to handle internal processes for various clients.


The application is a market place for cities and various community centres to sell their activities and courses like yoga or swimming class. It was dealing with registration, list of attendees, payments, tax deduction reports for the users and organizations, etc.

At first, we were mandated with writing a few functionality like search using Algolia and various reports. Over time our mandate grew and we ended up acting as an outside consultant and CTO to help their team fix their tech debt issues and to oversee the app rewrite. The app had been started by non-coders and interns and needed some serious structural changes for which the client retained our services for around to 2 years.

White label projects

I worked on white label projects for various agencies. As per the contract I cannot disclose the end client, but here is some example of projects we worked on.

Games and tools


I worked on a variety of games for Berzerk Studio. Here is some of them:


BaconBox was an open source game engine I started with partners. Freshly out of college, we were overengineering and using anti-patterns such as deep inheritance, which is why the engine went through 3 rewrites as we were learning best practices. The sources were previously hosted with mercurial, so some of the older code might have been lost.

The last version of the engine was a component-based engine. Similar to how Unity works.

The input/output and scripting layer were interchangeable. The games could be coded in Lua, C/C++ and some experiments were made with ruby.

The engine was rendering to standard low-level rendering APIs like OpenGL, Stage3D and eventually would have also supported DirectX. It was also able to render to more divergent rendering backend, like the vector-based API of the Flash runtime. We also toyed with rendering to CLI.

The engine allowed us to use the same codebase to port the flash games to mobile. Modifying only the assets.

We were also able to live reload code on iOS/android instead of going through the 20 minutes-long build time we were experiencing with unity, allowing us to iterate quickly.


BaconBox Flash Exporter

The Flash exporter was the tooling allowing us to transform complex flash animations to sprite map and xml files the engine could use to render outside of flash.

One of the big reason we were using flash animations was the ability to nest components together, name frames/framesets, name components. This allowed to do things like drawing the hit zone or put an invisible dot on the end of a rifle to get its position at run time to spawn the bullets.

Today most engine support this concept. Unity and Unreal Engine do this in their editor instead of using a separate outside program. As a small studio, we leveraged existing tools to do the same. The exporter I coded allowed us to extract this information from flash.



Generous was a "cross-platform/ide project builder generator" (that's a mouthful). We were using it to generate Xcode Projects, QtCreator Projects, Makefiles or just plain dumb scripts to build our engine and games on all our target platforms.

It was like autoconf, but supporting multiple "project" types, not just makefiles.

Project using Generous would be configured using yaml like this: BaconBox Generous project, with possibility of using a ruby DSL.



Libbuildtool was initially coded in bash and got rewritten in ruby. It was a way for us to build/download/prep the dependencies of a project. It was a little bit like nix packages expressions (but using a ruby DSL) allowing us to use predefined builders to easily describe how the build should go. We could overwrite any step of the process through hooks if we needed to patch the sources before building, for example.

It supported cross compilation and various build systems like CMAKE, Autoconf, etc. and

Here is the main libbuildtool file for BaconBox telling libbuildtool what libraries need to be built for the selected platform:

Here is an example of the DSL needed to build libpng:



I did not code CrossBridge (formerly alchemy and Flascc). CrossBridge was a C/C++ cross compiler for the ActionScript VM (Flash). Adobe abandoned it and we took it over with other contributors. We were trying to keep it alive by maintaining the documentation, forum, etc.

We also added new modules and functionality like the ability to load assets without precompiling them into the Flash bundle:

I let the domain expire and cancelled the hosting when adobe put the last nail in the flash coffin.

As much as people like to hate on Flash for its flaws (even me, the thing was full of bugs!) and incorrect use in advertising. For games it was pretty much the only solution for years. It took years for the browser to catchup on its functionalities. We were revisiting the idea of porting to HTML5 every few months because of the obvious flash decline. HTML5 was not quite there yet for bigger games and the web game market was still strong. Unity solved this by creating their own plugin, but you simply can't do that as a small studio (you'll never gain a wide user base). So we stuck with flash and experimented with compiling to unity for web versions of the games while we waited for HTML5 became more viable.