Basic idea
Every year, we spend a week working on internal projects to test our own ideas and explore new technologies. The focus is on having fun, and economic considerations take a back seat to our playful instincts. For five days, we simply do whatever we want. Here is a brief summary from the year 2026.
A platform for real-time collaboration with voice chat, multi-user screen sharing, and text messaging
Basic idea
Effective remote collaboration requires latency-free communication and a sense of “virtual presence.” A key element of this is the ability to easily share screens with multiple colleagues at the same time. Although Discord offers exactly these features from a technical standpoint, it is not designed for corporate use (data protection, integration capabilities). My motivation was therefore to create my own solution with a focus on professional collaboration.
Concept & Implementation
I deliberately chose a modern and experimental stack: The desktop application is based on WailsJS (as an alternative to Electron) in combination with SolidJS, while Pocketbase serves as the backend. My main technical goal for Dynaweek was ambitious: to implement a screencast video stream under Arch Linux and Wayland. This is technically challenging because Wayland enforces strict window isolation. The goal was to capture this local stream and distribute it to multiple users via WebRTC (LiveKit).
Findings & Outlook
The hurdles were higher than expected: WailsJS currently does not offer native support for video streaming, and Wayland's security protocols block conventional screen capturing methods. Instead of focusing on network transmission, I had to invest most of my time in “low-level” solutions (supported by AI debugging with Gemini 3 Pro) to even get to the image signal. The result: I managed to build a working proof of concept that successfully captures the screen under these difficult conditions and displays it in the app—a technical breakthrough for this stack. Transmission via LiveKit is the logical next step for Voca.
With the Nodarium web app and the Plantarium node system, users can generate 3D plants in a playful and visual way.
This week, three of us (Felix, Niklas, and Max) continued working on this project in different areas. The first challenge was to bring a project that had been developed by one person over a long period of time to a stage where several people could enjoy working on it together. To do this, Felix used the modern code formatter “dprint,” for example. He also cleaned up the code in many places and brought it up to date.
Meanwhile, Niklas and Max worked on the individual nodes, designed an optimized runtime for executing the individual nodes, and Niklas wrote the first prototype node in Zig. At the same time, the team significantly improved user interaction: The new drop node on connection feature allows nodes to be placed directly on a connection. The context menu now always remains in the visible area, and the camera position has been optimized so that all nodes are visible at startup.
Another highlight of this week was the implementation of a complete project manager system that allows users to efficiently organize and manage their projects. In addition, the Docker infrastructure was finalized—with separate Dockerfiles for the app and nodes as well as optimized deployment configurations. This also enabled feature branch deployments via Coolify.
The UI has been extensively modernized: integer and float input components have been redesigned, given min/max switches and keyboard integration (Esc/Enter), and a new header element has been added. The workspace structure has been migrated from links to real pnpm workspaces, and the development pipeline has been optimized.
Findings & Outlook
Further improvements in detail: Keyboard shortcuts are now accessible with ?, the graph context menu no longer moves when right-clicking and dragging, and all available nodes are visible in the Add menu. Build flags have been optimized for WASM, node build scripts have been cleaned up, and various minor fixes have been implemented – all in all, over 45 commits in five intensive days!
Tool for easy PDF generation based on Typst templates
Somehow, it's much too difficult to create a simple PDF. Typst/LaTeX are too complicated for the average user, and other document programs (e.g., Word) are too cumbersome for me.
You can upload Typst templates. Templates consist of a function called “template,” where you describe all parameters using annotations and attach metadata. Forms are automatically generated from the templates to transfer the parameters to the template. The final PDF is then generated from this. A major focus here is on client-side rendering logic. All PDF generation takes place in the browser. The server is only there to manage the templates. All templates are also public and you can get started right away without logging in.
Findings & Outlook
Typst can be compiled to WebAssembly out of the box, which has made it much easier to integrate into a website. The main difficulties arose from the combination of Angular and WebAssembly. The PDF preview ensured that the PDF itself was “consumed” and could no longer be downloaded in a later step. As a solution, I found URL objects that are not simply “consumed.” Overall, I had to combine Angular's high-level API with WebAssembly's low-level API, which forced me to come up with some unusual workarounds.
Currently, only normal text can be handled in the form. Executing these data types is the next step in making the tool useful and usable. These include, for example, dates, numbers, or even more complex structures such as lists or objects. In addition, template creation is still very undocumented and also allows incorrect entries. Here, the documentation and help for the user must be significantly improved.
The project simulates self-driving cars that use genetic algorithms and neural networks to learn independently how to drive efficiently and flawlessly on a race track.
The basic idea behind the project arose from the desire to avoid manually specifying the “ideal line” on a race track and instead allow the vehicles to learn it themselves.
An initial version of the project was developed back in 2024, in which the cars were able to drive around the track but did not yet exhibit independent learning behavior. In the current further development, this original goal has now been fully implemented.
Using self-learning algorithms, the vehicles make decisions independently, learn from mistakes, and improve their driving style over several generations. The motivation for this lies both in an interest in motorsport issues—in particular, the calculation of optimal racing lines—and in an enthusiasm for video games and simulation-based systems.
Concept & implementation
At the heart of the project is a racing simulation in which autonomous vehicles independently learn and drive a freely definable race track. Each vehicle makes its own driving decisions—accelerating, braking, and steering left and right—based on sensor data such as distance to the track, speed, and direction of travel. An ideal line is not specified, but is to be found independently through repeated driving.
A genetic algorithm was used for implementation. A population of vehicles drives the track, is evaluated based on its performance, and then serves as the basis for the next generation. Through targeted mutation and combination of decision parameters, new driving strategies emerge over several generations.
The route is divided into individual sectors, which means that even incomplete journeys can be evaluated in a meaningful way. In addition, driving data such as sector and lap times are recorded and visualized in order to clearly show the learning progress of the vehicles.
Findings & Outlook
Defining a suitable fitness function proved to be much more difficult than initially expected. Minor changes to the evaluation sometimes led to extreme or undesirable behavior, such as cautious driving, early braking, or completely avoiding curves. Finding the right balance between speed, progress, and stability required a lot of experimentation and fine-tuning.
One deliberate simplification was to use only one type of vehicle. All vehicles had identical physical characteristics such as acceleration, braking power, and top speed. This allowed the learning process to focus entirely on driving behavior. At the same time, this represents an idea that was not implemented: different vehicle types with their own strengths and weaknesses would have enabled interesting additional dynamics.
Several enhancements are conceivable for the future. These include different vehicle classes, more complex sensor technology, more adaptive fitness functions, or even learning across multiple tracks. It would also be possible to further develop the system in the direction of realistic motorsport simulation or to optimize the AI specifically for certain driving styles.
Browser-based, interactive web app that transforms live camera input into dynamic visual experiences, seamlessly switching between different generative sketches.
The idea arose from the desire to create an interactive web app that captures live camera input, transforms it, and converts it into various visual representations—without recognizing or classifying identities.
The system is designed to function as an autonomous interface that continuously evolves, even without direct interaction. The motivation was to develop a modular system that enables different visual approaches and is optimized for use in a browser.
Concept & implementation
Residual Surface was developed as a fully browser-based application that combines several independent generative sketches in a unified system. Each sketch uses the live camera as raw material and transforms this input in different ways: from physics-based fragments with Matter.js to organic particle flows with Perlin noise to abstract paintings and ASCII camera visualizations.
The biggest technical challenge was developing a clean plugin architecture that allows sketches to be switched seamlessly without causing memory leaks. In particular, the correct cleanup of Matter.js physics engines when switching sketches required careful lifecycle management. The solution was a registry system with clear setup, draw, and cleanup phases for each sketch, combined with centralized state management for shared resources such as the camera.
Another challenge was performance optimization for continuous operation in the browser. By limiting the number of fragments, delta time capping for physics simulations, and optimized canvas rendering strategies, stable 60 FPS performance was achieved. The application was also designed for graceful degradation—it works even without camera access and automatically recovers from errors without blocking the application.
The system supports both image and video capture (PNG/WebM) and offers a dynamic toolbar that automatically adapts to the parameters of the active sketch. The architecture makes it easy to add new sketches by implementing the sketch interface and registering the sketch in the registry.
Findings & Outlook
The choice of a plugin architecture with a clear interface has proven to be very valuable, as it greatly simplifies the development of new sketches and improves code maintainability.
Properly cleaning up Matter.js physics engines when switching sketches was more complex than expected and required several iterations to eliminate all memory leaks.
Planned features / Ideas not implemented:
Presence detection via TensorFlow.js to modulate visualization based on movement
Network synchronization for multiple instances sharing fragments
Time-based sketches that change their behavior depending on the time of day
An N8N workflow that sorts incoming support emails, labels them, and then either composes a reply or forwards the email to the appropriate department depending on the category. The Gemini 3 model was used to sort emails, label them, and compose replies.
Our customer is currently experiencing issues with processing support tickets, and dynabase would like to build expertise in N8N and automation in general.
Concept & implementation
An n8n workflow with Gemini Agents was implemented for the automated analysis, categorization, and forwarding of incoming support emails.
Findings & outlook
With N8N, you can quickly put together a prototype, but it quickly becomes confusing when you build larger workflows. As a software developer, I naturally have a bias and tend to feel better when I write code, but for someone who is not a software developer, N8N is a good tool for implementing their ideas.
Gophper is a language server for the PHP programming language. It supports developers in their programming by determining relevant suggestions for editors and transmitting them via the Language Server Protocol (LSP).
PHP is a widely used language for which there is currently no free and high-performance LSP implementation. Existing implementations are either proprietary or written in PHP itself, which is significantly slower than in other languages due to the lack of concurrency. Our goal was to create a PHP LSP implementation that is more performant than existing solutions and is also open.
Concept & implementation
Due to the low barrier to entry and the relative ease of use of concurrency, we decided to use Go as the basis. For parsing, we initially opted for a PHP solution, as this would be able to generate an AST that already contains a lot of information that we would otherwise have to determine ourselves. However, due to some limitations, we had to abandon this plan. Ultimately, we decided on Tree-sitter. Tree-sitter is established, extremely performant, and maintained by the community.
Findings & outlook
One thing we learned was that PHP itself is not slow at all. A test project with just under 20,000 files could be parsed in 24 seconds using PHP alone.
Initiating the PHP process from Go and having each file parsed individually was even slower at just under 60 seconds, despite concurrency, because we had the overhead of having to restart PHP repeatedly.
We also learned a lot about the (lack of) scoping in PHP with regard to variables, functions, and classes.
The same applies to namespaces in PHP. We learned that there are two different types of namespaces syntactically and that you can define multiple namespaces within a file.
Kana is a memory-style card game.
Kana originated from a previous Dynaweek project.
Concept & implementation
Over 200 card artworks were generated to build a highly complex memory game with an extended set of rules.
Findings & Outlook
A functioning memory game with a complex card viewer was built. There are a number of features that still need to be implemented.
An Obsidian extension that synchronizes tasks with a CalDAV calendar based on a defined keyword and compares their status bidirectionally.
Obsidian offers native support for recording tasks. With the help of the Tasks Extension, these can be expanded to include metadata such as due date or priority.
However, since Obsidian does not support push notifications and tasks or reminders are not necessarily maintained exclusively in Obsidian, media discontinuity can quickly arise. To ensure a consistent and centralized overview, it is advisable to synchronize tasks with an external CalDAV task list.
Concept & implementation
As part of the project, a functional prototype of an Obsidian extension was developed that automatically adds tasks to a CalDAV calendar based on a defined keyword. In addition, existing calendar entries and the status of already synchronized tasks can be manually retrieved from the CalDAV server and synchronized with Obsidian. The extension fully supports the syntax of the Obsidian Tasks Extension, allowing due dates to be defined directly in Obsidian and seamlessly synchronized.
The main technical challenges lay in the secure handling of access data. These could not be conclusively resolved, as CalDAV servers often rely on basic authentication in practice, which is problematic from a security perspective, as this could be stored in plain text in a JSON on a server.
Another obstacle is CORS restrictions when using existing NPM packages. These were circumvented by, among other things, implementing a proprietary CalDAV client.
Findings & Outlook
The consistent orientation towards Obsidian's existing task syntax proved to be a very good design decision and facilitated both the use and extensibility of the extension.
On the other hand, secure credential management in the context of CalDAV proved to be unexpectedly complex.
Planned enhancements include: fully automatic bidirectional synchronization (2-way sync), support for calendar entries, and support for times in due dates.
S&box Colonizer is a PC port of the mobile real-time strategy (RTS) game “Colonizer,” which is based on the Source 2 engine and has been expanded to include online PvP support.
The original mobile game suffers from the typical limitations of the platform: imprecise touch controls, weak AI opponents, and a lack of multiplayer functionality. At the same time, the development of the new S&box platform (based on Valve's Source 2 engine) by Facepunch provided an opportunity to familiarize ourselves with this technology at an early stage. The goal was to have a high-performance, finished game ready for the planned release of S&box in Q1 that would remedy the weaknesses of the original with mouse control and real networking.
Concept & implementation
A peer-to-peer RTS game was developed with a “multiplayer-first” approach. The biggest technical challenge was implementing our own network code to simulate over a hundred room units simultaneously and smoothly. A game object pool was implemented to spawn units (game objects) without performance drops (lag spikes). This serves to keep a number of inactive game objects in memory and reuse them as needed, instead of recreating and destroying them again in a computationally intensive process (garbage collection). The network approach is deterministic: the host sends the position and rotation of a new ship once, whereupon all clients calculate the movement independently and identically (deterministically) over the next frames.
Findings & Outlook
The complexity of implementing our own network was underestimated. It became apparent that deterministic synchronization between clients is much more complex than expected, as even the smallest deviations lead to desynchronization. One positive learning experience was the effectiveness of object pooling in the Source 2 engine, which greatly improved the gaming experience. For the future, we plan to integrate a “prediction” logic so that the host can detect and correct asynchronies before they become visible to the players.
Flip 7, a card game, was recreated as a web application with online multiplayer.
To recreate a simple game in a short amount of time in order to better understand distributed systems and client/server collaboration.
Concept & implementation
During Dynaweek, I tried to build a web application in a short time that would allow people to play Flip 7 with others. Both the rules and the presentation were a technical challenge. How do you combine server state and client state while animating everything in an appealing way? What would a good protocol for such an application look like?
For the first draft, I built a simple machine that maps the rules of Flip 7. In the second draft, I built a wrapper around it so that this machine could be operated via a WebSocket connection and changes in state could be communicated. In the final step, an Angular application was built that can visualize this state and allows interaction with the machine.
Findings & outlook
While standard development tasks come easily to me, I found that fine-tuning and good UX were much more difficult. Therefore, as a developer, it would be worthwhile for me to sketch out the end result before writing the code.
A decentralized review platform for places (such as restaurants and cafés) based on the AT protocol.
The motivation behind Dereview is to make reviews of physical locations independent of central platforms (such as Google Maps or Yelp). By using the AT protocol, users retain control over their own data (reviews), while the platform merely aggregates it and makes it available in a decentralized manner.
Concept & implementation
As part of the project, a complete ecosystem for decentralized reviews was developed. This includes:
Lexicon design: Definition of the app.dereview.review lexicon to store structured data such as star ratings, titles, descriptions, and location IDs (based on OSM node IDs) in the ATProto network.
Ingester service: A specialized Node.js service that scans the entire AT network in real time via Jetstream for review events and indexes them in a PostgreSQL database. User profiles (handles, avatars) are also automatically completed.
Web-App (Next.js): A modern interface that uses map integration (Leaflet) to display locations and allows users to securely publish their own reviews via OAuth.
Findings & Outlook
The decision to separate the architecture between Ingester and the web app (microservices) was a very good one, as it optimizes load distribution. Plans for the future include image uploads directly to ATProto blobs and an “upvote” system for particularly helpful reviews.
DynaWeek #8 in 2026 once again demonstrated what dynabase stands for: curiosity, technical depth, and the freedom to explore ideas without economic pressure. Over the course of a week, prototypes, experiments, and systems were created that addressed a wide range of issues—from real-time collaboration and workflow automation to generative web experiences, self-learning racing simulations, and new approaches to PDF generation.
Whether complex low-level experiments under Wayland, the expansion of a modular node architecture, AI-supported automation, or browser-based real-time visualization: the projects show how broad the technological spectrum at dynabase is – and how much energy is generated when teams are given room to experiment.
DynaWeek thus remains what it is meant to be: a playground for new ideas, a testing ground for technologies, and an integral part of our culture, which focuses on learning, experimenting, and joint development.