Badge builder

Context

At Eventmaker, every attendee of a trade show or conference leaves with a badge. These badges are generated by badge-core, an in-house C++ engine that has produced millions of them. It's robust and fast, but it only reads one format: three JSON files (content, view, style).

Creating a badge therefore meant writing JSON. Clients couldn't do it themselves, project managers took a long time to learn it, and developers were regularly pulled in.

A first design in 2022

In 2022, the team's designer created a first builder under my supervision, modeled on our email and website builders. The design was approved, but it was never developed. Elements were positioned by typing X and Y coordinates, with no live preview.

The project was then put on hold. When it came back up in early 2024, prototyping in code no longer took weeks thanks to AI: for something as visual as a badge, I could show something that works rather than another mockup.

A coded prototype

In March 2024, I developed a prototype with Fabric.js, an open source canvas library that handles drag and drop, multiple selection and live preview. You could move, resize and align elements, and the canvas produced JSON.

To check compatibility with what existed, I converted the three files of a real badge to the Fabric format. I presented it all in a pitch, raising the question I couldn't settle on my own: what to do with the rendering engine?

The rendering question

The CTO's answer refocused the problem. Converting the JSON wasn't the main difficulty; rendering was. badge-core produces a print-ready PDF, Fabric draws on a canvas. Replacing a proven engine with a canvas-to-PDF conversion carried risks: multiple pages, fonts, performance.

We ended up with an architecture sturdier than either of our initial proposals: badge-core for rendering, unchanged, Fabric.js for editing, and a converter between the two. The editor sticks to what the engine can print: no rotation at first, for example.

The data format stayed the same: existing badges kept working, and could be opened in the new editor.

A week later, a developer had validated the approach: text placed on the canvas showed up in the same spot in the PDF.

From prototype to product

The same designer then made the interface mockups. We studied the leading editors, starting with Canva and Figma, to reuse the gestures users already know: alignment, snapping grid, keyboard shortcuts, history. To speed up development, I gathered open source Fabric.js examples and extensions that the team could adapt.

Usage, two years later

The starting goal was client autonomy. Over five weeks in fall 2026:

• 137 client users opened the builder, across 165 events, six times more than the internal team
• 58% of the events where a client looks at their badges go through the builder

Over time, the trend is the same. According to analytics, the number of client users who open the builder each month nearly doubled from one September to the next, and it caught up with the old template form in October 2026:

JSON hasn't disappeared, though: the internal team still uses it for the most complex badges of large shows or festivals, which the builder can't produce yet. That's the limit we chose at the start, and the logical next step for the project.

What I learned

This project confirmed that a working prototype moves a discussion forward faster than a mockup: the debate went from "is it feasible?" to "how do we make it reliable?". And it was by openly laying out what I didn't know that we found the right architecture.

Team

• Robin Monjo, CTO: badge-core and the rendering question
• David Huveau and Elena Verona, builder development
• Nadia Tefridj, builder design, from 2022 to the shipped version