At the 2026 Kitsu Submit, Guilhem Compain, lead developer at Wizz Studio, took the stage to walk attendees through a challenge many smaller studios know well: managing a variety of projects across radically different animation techniques, with a small team and tight deadlines.
His talk covered the technical choices Wizz has made and a practical guide for any studio trying to bring structure to a hybrid pipeline without losing the flexibility that creative work demands.
A Small Dev Team With a Big Mandate
Wizz is a Paris-based animation studio founded in 2004, with around 20 employees and 40 permanent artists. It is part of the Quad group, which also includes Quad Film, Quad Drama, and other production entities.
What makes Wizz unusual is the sheer range of techniques it works with: 2D frame-by-frame animation, 3D, stop-motion, motion design, and mixed media all live under the same roof. The studio produces primarily short series, trailers, teasers, and music videos, with the occasional fiction project.
That diversity creates operational complexity. Wizz works across many software tools, including TVPaint, Photoshop, Nuke, and Blender, among others. Each production can look entirely different from the last, and productions rarely last more than a few months so speed and clarity are not optional.
Guilhem was direct about the context in which all of this happens: the Wizz development team consists of exactly two people. He joined about a year ago, and the other member, pipeline TD Hadrien Farre, has been at the studio for four or five years. That scale matters for everything that follows.
"We have a dev team that is quite small," Guilhem noted. "There are two of us, and that inevitably has an impact on what we're able to produce and implement in our pipelines."
This is a recognizable situation for many mid-sized studios. The challenge is not understanding what a good pipeline looks like but building and maintaining one with limited resources, while still shipping work.
The Role of Kitsu at Wizz
Kitsu serves as one of two central pillars in Wizz's infrastructure. The other is QuadPype, their internal pipeline tool built as a fork of the open-source OpenPype (now known as AYON in its fourth version). Together, Kitsu and QuadPype act as what Guilhem calls an abstraction layer: rather than allowing different software tools to communicate directly with one another, everything passes through one of these two systems.
"It gives us a certain sovereignty over our data," Guilhem explained. "Only Kitsu, primarily, holds the important data. All the software connects to it. It prevents software from talking directly to each other."
For studios that have experienced the chaos of undocumented inter-tool dependencies or lost production data when one application in a chain breaks, this kind of centralization will be familiar as a solution. Kitsu becomes the authoritative record of what exists, what has been approved, and what still needs work.
Guilhem emphasized that Wizz's use of Kitsu is intentionally simple. They do not take advantage of every feature the platform offers. Instead, they lean on Kitsu as a visualization and tracking tool: a place where coordinators, directors, and production staff can see the state of a project at a glance, without having to dig into a filesystem or ask an artist directly.
Assets are tracked through tasks, comments, and retakes. Shots follow the same logic.
Sequences are used more loosely than the traditional animation sense of the word: at Wizz, a sequence might represent everything related to colorboards, or it might distinguish trailer work from the main project.
The structure is adapted to how the production is actually organized, not forced into a rigid framework. Breakdowns handle casting, which then feeds downstream into pipeline tools. Playlists generate quick on-the-fly edits that directors can review and annotate directly.
Where Kitsu Connects to the Pipeline
The talk then covered how Kitsu data flows into QuadPype for automation.
Wizz runs a synchronization service on a dedicated server. This service listens to Kitsu's event system, which fires an event every time anything changes in the platform: a status update, a new comment, a task being assigned. The sync loop captures those events, filters them for relevance, and writes the results to a local database that QuadPype queries.
"Every time you do something in Kitsu, it triggers an event that anyone can listen to," Guilhem explained. "We filter all the captured actions to keep only the ones we care about, and for each relevant event, we run code that adds, modifies, or deletes data in the database."
One notable addition the team made, beyond what OpenPype offered out of the box, was including casting information in that sync: when an artist opens a scene, QuadPype can now automatically load the correct assets, props, and elements based on what was cast in Kitsu. This removes a manual step that would otherwise fall on artists to remember and execute correctly every time.
From there, the data flows into the launcher, which is effectively QuadPype's asset manager. Artists see their projects, assets, and shots pulled directly from Kitsu. They can see at a glance which files exist on the filesystem and which have been published. They select their shot, select their task, and open it in the appropriate software.
Publication follows a similar logic. When an artist publishes their work, the publisher pulls configuration directly from Kitsu: frame start, frame end, and any other relevant parameters that have been set for that shot. Sanity checks run automatically, verifying that the artist's file matches what Kitsu specifies. If the frame range does not match, the system flags it before the publish completes.
The final feature Guilhem highlighted is what they call "Build First Workfile." This tool reads the casting information from Kitsu, then automatically generates a starting scene, organized according to a predefined structure, with all the correct elements already loaded. For artists beginning work on a new shot, this eliminates a significant amount of manual setup.
The Hard Problem: 2D Artists and Pipeline Culture
Guilhem spent time on something that pipeline discussions often sidestep: the cultural gap between 2D and 3D production.
"In 2D, there's this notion that a 2D pipeline should be 'organic,'" he said. "Meaning the artist should be free to do whatever they want without any constraints. On the other hand, a 3D pipeline aims to really restrict what artists can do to avoid technical problems later on. Obviously, the right answer is somewhere in between."
This tension is real in practice. 2D workflows have historically developed in smaller, more informal environments where artists manage their own file organization and naming conventions. Introducing a pipeline tool means asking those artists to change habits that, from their perspective, have always worked fine. The resistance is not unreasonable.
Guilhem described specific friction points at Wizz. For example, artists on Windows tend to copy and paste files with accented characters in the filenames, which causes downstream problems in the pipeline. Rather than blocking the action entirely, Guilhem argued for silent correction: let the file through, but rename it automatically. "Framing without it being visible, that's the goal," he said.
The adoption process is still ongoing. "I don't think there will ever be a moment where everyone is satisfied," he acknowledged.
The recommendation he offered was less a technical one than an organizational one: talk to people first. Understand how different artists actually work, involve them in decisions about what constraints make sense, and let the tooling follow from that understanding rather than the other way around.
What Comes Next
Guilhem closed with a list of improvements the team wants to make like filtering the launcher view to show only the tasks assigned to a specific artist (a feature that already exists in AYON's repository and can be adapted for QuadPype), in-app notifications when Kitsu statuses or comments change, and pulling Kitsu comments directly into the software so artists do not have to context-switch to a browser.
He also pointed to a broader aspiration: the ability to write something once in QuadPype and have it work across every software integration automatically. "That's where pipeline tools like QuadPype, OpenPype, or AYON really shine," he said. "You can write something once and it works across all software, since each integration lives somewhat outside the software itself even though it communicates with it."
For studios on a similar path, the Wizz pipeline is available on GitHub at quadproduction/QuadPype.
Key Takeaways for Studios
The Wizz story offers a grounded view of what it looks like to build around Kitsu in a real, messy, multi-technique production environment. A few points stand out for studios in a similar position:
- You do not need to use every Kitsu feature to get value from it. Wizz uses Kitsu primarily as a visualization and tracking layer, and that alone delivers significant benefit to coordinators and directors.
- The value compounds when Kitsu becomes the authoritative data source for downstream tools. Frame ranges, casting, task status: anything you record in Kitsu can be used to configure, validate, and automate work elsewhere in the pipeline.
- The technical challenge of integration is real but manageable. Wizz built their sync layer on Kitsu's own event system, which is well-suited to this kind of use.
The harder challenge is organizational: getting artists to trust and use a system consistently enough that its data stays reliable.
And if you are running a hybrid studio, the 2D/3D cultural divide around pipeline discipline is worth acknowledging directly. The tools are only as good as the habits that surround them.
