PCB design software is already mature.
KiCad provides a capable open-source EDA environment. Altium and other commercial systems support sophisticated professional engineering workflows. EasyEDA has made browser-based electronics design accessible at significant scale. Flux is exploring what a cloud-native, collaborative electronics environment can look like.
ZIRO Designer starts from a different question:
If we were designing an open PCB engineering environment around today's software infrastructure, what architecture would we choose?
For us, the answer was browser-native, but not browser-only.
The browser as an engineering runtime
The immediate benefits of browser software are familiar: no installation, cross-platform access, and simple distribution. Those were not the primary reasons we chose it.
A PCB editor is a soft real-time application. When an engineer drags a footprint, pushes a trace, or pans across a dense board, the view has to update within a single frame, on the order of sixteen milliseconds, or the tool feels broken. That budget is the constraint that shapes the entire client.
A lot has to happen inside it. The canvas re-renders thousands of primitives. The cursor hit-tests against pads and traces. Positions snap to the grid and to existing geometry. Design rules are checked incrementally around the edit, and copper zones reflow. Each of those is a geometry and compute problem, and each has to finish before the next frame. A network round trip, even a fast one, does not fit inside that budget. This is the first reason interactive work runs on the client: not because local is philosophically better, but because the latency budget leaves no room for anything else.
The browser gives one main thread for the interface, so the heavy work cannot sit on it. Rendering has to lean on the GPU, and geometry, hit-testing, and rule checks have to stay off the main thread, so the interface never blocks waiting for them. The board itself, the authoritative model of nets, footprints, and copper, has to be laid out so that work can read and update it quickly, indexed for spatial queries rather than walked linearly. Getting that data model right is much of the work in an interactive EDA client, and it is the part a desktop-first architecture tends to get wrong for the web.
Projects follow the same logic. They are held locally, in the browser, and synced to the cloud in the background, so work stays available offline and across machines without a design ever being trapped inside a single client.
Moving a footprint should not require a round trip to a data center. Neither should panning across a board, drawing a wire, or inspecting a component. At the same time, not every EDA workload belongs on the client.
Browser-native does not mean browser-only
Circuit simulation, computational analysis, optimization, and future intelligent placement and routing have very different compute requirements from interactive editing. So ZIRO's architecture separates the engineering interface from compute infrastructure.
The principle is straightforward:
Interactive workloads execute locally. Compute-intensive workloads can execute remotely when appropriate.
The line between them is not the client/server boundary people usually picture. It is drawn by two variables: how latency-sensitive a workload is, and how expensive it is to run.
Interactive editing is latency-sensitive and, per operation, cheap, so it stays on the client. A full-board simulation, an electromagnetic solve, a global autoroute, or an intelligent placement pass is latency-tolerant and expensive: an engineer starts it and waits seconds or minutes for a result. That kind of work has nothing to gain from a frame budget and everything to gain from real hardware, so it can run on infrastructure instead of pinning the tab. In between sit the awkward cases, incremental checks on a very large board or push-and-shove routing physics, that are heavy but still interactive. Those belong on the client too, because latency wins.
One consequence is worth stating plainly. If a design-rule check can run either in the browser or on a server, both have to produce exactly the same result, down to the last clearance violation. Two separate implementations would eventually drift apart. That pushes the architecture toward a single geometry and rules engine that runs in both places, so the compute boundary becomes a line where the same code executes on different hardware, not a seam where two different tools meet.
It also means a ZIRO Designer session does not have to correspond to a continuously running cloud workstation, and it leaves room as engineering workloads grow more demanding.
Why not WebAssembly an existing EDA application?
WebAssembly makes it increasingly practical to execute substantial native software inside browsers. It is an important technology, and there are cases where compiling an existing engineering codebase to WASM is exactly the right solution.
Our objective, however, was not simply to make a desktop EDA application executable inside a browser tab.
A native desktop application carries architectural assumptions around its UI toolkit, filesystem, processes, threading, persistence, plugins, and operating-system integrations. Those assumptions can be adapted for the web, but doing so answers a different problem:
How do we run this application in a browser?
We were interested in a different one:
How should an EDA environment be designed if the browser is one of its native environments from the beginning?
That distinction influences everything from project persistence to collaboration and repository integration.
A desktop EDA application is built on assumptions that do not survive the move on their own: a real filesystem, operating-system threads, blocking I/O, a native widget toolkit, binary plugins, and a single user working alone. Compile that to WebAssembly and you get the same application, in a tab. What you do not get is multi-user editing, background cloud sync, sharing a design with a link, or moving a workload to a server, because none of those were in the original architecture. They have to be designed in, not compiled in.
Why not stream a desktop workstation?
Cloud-hosted desktops provide another viable architecture. Run the EDA application on infrastructure, stream the rendered interface to the browser, and send user input back.
This is particularly useful when an organization needs centrally managed workstations, controlled environments, or access to computational resources unavailable on the client.
The failure modes are specific, though. Because every interaction, every keystroke and mouse move, makes a round trip to that machine and waits for a frame of video to come back, the experience is only ever as good as the network in between. Because each session is a live machine, cost scales with the number of people connected at once rather than the work they are actually doing. And a streamed desktop gives up the things the browser is genuinely good at: local files, offline work, and integrating with the rest of the web.
ZIRO Designer instead uses the compute already sitting on an engineer's machine for ordinary interaction, and reserves infrastructure for the work that genuinely benefits from it. That is an architectural choice rather than a claim that one model is universally superior.
Building around KiCad
Once we decided to build a new browser-native implementation, interoperability became one of the most consequential decisions.
Creating a new EDA application makes it tempting to create a new project format. We chose not to. ZIRO Designer is being built around the KiCad ecosystem and its open design formats. This means the project file remains an engineering artifact independent of ZIRO's existence.
The broader objective is simple:
Using a browser-based engineering environment should not require adopting another isolated PCB file ecosystem.
This decision has significantly increased the engineering work required to build ZIRO Designer. Compatibility means implementing details that are easy to overlook: serialization, geometry, units, libraries, layers, properties, editing behavior, and numerous edge cases.
We consider that cost worthwhile. Interoperability is part of the architecture, not a migration feature.
Different tools, different engineering workflows
There is already a diverse ecosystem of electronics design software, and the differences between these systems are more useful than pretending they solve identical problems.
KiCad is particularly compelling for engineers who want a mature, open-source desktop EDA suite, local control over their workflow, and access to the established KiCad ecosystem. Its architecture is primarily desktop-oriented rather than browser-native or multiplayer.
EasyEDA combines browser-based electronics design with deep integration into the LCSC and JLCPCB component sourcing and manufacturing ecosystem, which makes it particularly useful for rapid design-to-fabrication workflows in that ecosystem.
Flux takes a cloud-native approach, with real-time multiplayer collaboration and AI-assisted workflows integrated directly into the electronics design environment.
Altium Designer and Altium 365 address professional and enterprise development, pairing a mature desktop EDA environment with cloud-based data management and collaboration.
ZIRO Designer takes another architectural position: open source, browser-native, interoperable with the KiCad ecosystem, with interactive computation running locally and infrastructure available for the workloads that benefit from it. Describing each tool by its architecture, rather than ranking them, is enough to show where ZIRO differs.
These decisions also shape what we want to build next.
From files in Git to PCB engineering with Git
KiCad projects are already frequently stored in Git repositories. That does not necessarily make the PCB workflow itself Git-native.
A text diff is excellent for source code. It is much less useful when an engineer wants to answer:
- What changed electrically?
- Which component moved?
- Which trace changed?
- What changed between these two board revisions?
- Does this change introduce a design issue?
Repository integration in ZIRO is intended to eventually connect version-control concepts to the engineering representation of the project, rather than treating PCB files as arbitrary repository objects. A browser-native environment gives us an interesting surface for building that interaction.
Collaboration
The same applies to collaboration. A PCB project is a structured engineering model, not a generic document.
Two engineers editing the same project raise questions about components, nets, geometry, constraints, and conflicting engineering operations that do not exist in a text editor. Concurrent editing of a board is a different problem from synchronizing a document, and it is one we are actively developing for ZIRO Designer.
The initial release
The first public release of ZIRO Designer is the core engineering environment: browser-native schematic capture and PCB layout, built around interoperability with the KiCad ecosystem. It is the foundation the rest of this direction extends from.
Open source
ZIRO Designer is open source. For us, this follows naturally from the interoperability decision. An open engineering format combined with a closed implementation would solve only part of the problem.
PCB designs can represent years of engineering work and substantial intellectual property. We think engineers should have the ability to inspect, modify, and independently run the software that operates on those designs. It also makes ZIRO Designer something others can extend, rather than simply a service they can access.
Beyond the editor
ZIRO Designer is also infrastructure for a broader research direction inside ZIRO EDA. We are working on Intelligent PCB Engineering: systems capable of participating in engineering tasks involving placement, routing, constraints, and design reasoning. This is separate from the ZIRO Designer launch.
The distinction matters. Adding a language-model interface to an EDA application is relatively straightforward. Building systems that can make useful PCB engineering decisions under electrical, geometric, manufacturing, and physical constraints is a much deeper problem. That is the problem we are interested in.
And it reinforces why we started with the engineering environment itself. Intelligent engineering systems need structured access to designs, deterministic tools, verification mechanisms, and an environment in which their actions can be inspected by engineers. ZIRO Designer provides that foundation.
Developing in public
From here, development continues in public. Collaboration, repository workflows, engineering infrastructure, and our research into intelligent PCB engineering will land as they become ready. We would rather document that work through releases and technical writing than concentrate everything into a single moment.
The browser is not the objective. Neither is reproducing a desktop EDA application on another platform. The objective is to build an engineering environment that combines the openness of the existing PCB ecosystem with the collaboration, infrastructure, and computational models available to modern software.
That is the direction we are taking with ZIRO Designer.
ZIRO EDA. Advancing PCB Engineering.
Building it with us. ZIRO Designer is usable now in early access, and public beta launches August 15. The team hangs out on Discord: come try it, tell us what breaks, and help shape what ships next.
Join the Discord →