How Wezoo lets non-engineers contribute to Windmill through workspace forks
Wezoo's solo Head of Engineering opened up internal automation to a non-developer team by replacing Git sync with workspace forks as the contribution model, keeping AI-built apps reviewable without forcing everyone to learn Git.
About
Wezoo is an online booking platform for flexible office space: meeting rooms, day offices, hot desks and longer-term private offices. It works with many coworking and hotel brands across the EU, US and UK, with more than 2500 locations bookable through the platform. Behind the product, Wezoo runs as a lean startup: a handful of full-time team members, a rotation of interns and freelancers, and a single Head of Engineering responsible for everything tech.
Windmill has been a cornerstone of Wezoo's backend operations from when the platform had only a couple of locations all the way to today's 2500+. Wezoo runs a self-hosted Windmill instance on Kubernetes to cover both internal tools and automations.
The problem
Wezoo started with Windmill the classical way: apps and dashboards for the operations team to review bookings, edit locations and run administrative tasks. That worked well when one engineer was the only builder and the rest of the team were operators.
As the team started experimenting with AI coding agents, the picture changed. Non-engineering colleagues, mostly in marketing, sales and business operations, began drafting their own internal apps locally with Claude Code and the Windmill MCP server. The output was promising but the contribution surface was now larger than Yuri alone, and the existing Git sync workflow that Yuri used to manage his own changes did not translate well to the rest of the team.
"Git sync works fine for me, but it's a complicated concept for non-developer people to understand."
Yuri van Geffen, Head of Engineering at Wezoo
The constraint was not the building, AI agents handled most of that, but the contribution loop: how does a non-developer ship a script or an app into a self-hosted Windmill instance without learning Git, without accidentally touching production, and without blocking on Yuri for every edit?
The solution
Workspace forks as the non-developer contribution model
Instead of pushing the rest of the team toward Git, Yuri pushed the contribution model toward them. Non-developers now work inside forked workspaces: full copies of the production workspace where they can iterate without touching the live setup. Yuri reviews and merges back when the change is ready.
"For their workspaces, they use the forking functionality. I might imagine that we all migrate towards that at some point, and just have Git as a backup for the source code."
Yuri van Geffen
The mental model is closer to what the team already knows: a personal copy you can mess with, a clear handoff back to the main instance through review. Git stays in place as the source of truth for Yuri's own work and as a backup of the production workspace, but it is no longer the only path into the platform.
AI agents and MCP for local building
On the building side, non-developers pair an AI coding agent (mostly Claude Code) with the Windmill MCP server. They draft scripts, flows and apps locally, with the MCP server providing context about the available Windmill primitives. Once a piece is in good enough shape, Yuri helps export it into their forked workspace where it can actually run against Wezoo's infrastructure.
"The visualness of Windmill makes things understandable, and the MCP integration makes it quite useful for me to explain things to them. It's the best moment in time to at least try it."
Yuri van Geffen
The visual editor matters here for a second reason: even when the original author is an agent, someone else on the team still needs to read the result. A flow that renders as a graph and an app that renders as a form are reviewable by people who would not read raw code.
One workspace per non-developer, sandboxed access
Non-developers each get their own forked workspace rather than dropping straight into production. That keeps the blast radius tight: each contributor only has access to the backend endpoints and resources they actually need, and an experiment that goes wrong stays inside the fork. Yuri's role on the backend has shifted accordingly: less building dashboards himself, more exposing the right scripts and endpoints so the rest of the team can compose with them safely.
"We're a small team, so we need everyone to be able to automate some parts of the operation themselves without relying on me."
Yuri van Geffen
Operational dashboards remain a load-bearing part of the setup. Bookings, locations and customer admin still flow through Windmill apps the team uses every day. The forks model sits on top of that foundation, not in place of it.
Self-hosted on Kubernetes
Wezoo runs Windmill self-hosted on their own Kubernetes cluster. That keeps customer data inside their infrastructure and gives Yuri the level of control he wants over how the platform is deployed and updated.
The result
Wezoo runs its internal tooling, integrations and growing fleet of AI-built apps off a single self-hosted Windmill instance, maintained by one engineer. Non-developers can now ship into the platform without learning Git, working inside forked workspaces that get reviewed and merged back into production.
The split is clean: Yuri keeps Git sync for his own work and for production backup, the rest of the team contributes through forks, and AI agents handle the bulk of the drafting on both sides. For a four-person operation, that is the difference between one bottlenecked engineer and a team that can automate its own work.
"We're probably going to be using Windmill more and more, also because of the rest of the team onboarding as creators and not just as operators."
Yuri van Geffen