KiCad Myth-Busting: What It Can't Do vs. What People Think It Can't Do
By the CADPreview Team · Series: KiCad is Enough
"The most expensive limitations are the ones that aren't real."
Fit for purpose engineering starts with an accurate picture of the tool. Not the one from five years ago. Not the one passed around the office. The actual one.
Let me say something that will irritate people on both sides of this debate:
Most KiCad criticism is five versions out of date. And KiCad does have real limitations. Both things are true.
Engineers rarely separate them. The result is a blurry reputation, part myth and part legitimate constraint, that makes it genuinely hard to decide whether KiCad is right for your team. You end up with colleagues who dismissed it in 2019 and never looked again, sitting next to colleagues who'll tell you it can do everything Altium can if you just configure it right.
Neither is a useful position to design hardware from.
The Myths: What KiCad Can Do That People Assume It Can't
"The component libraries can't be trusted"
This lingers from the early days, when footprint quality was genuinely inconsistent. It's no longer a fair description. The official libraries are maintained on GitHub with a formal review process, and pull requests are reviewed against documented standards before merge.
The correct position for any critical component in any EDA tool is to verify the footprint against the datasheet before you commit to a layout. That's not a KiCad problem. That's just engineering.
"Manufacturers won't accept KiCad outputs"
KiCad outputs Gerber RS-274X and Excellon drill files. That's the industry standard. The manufacturing files carry no KiCad fingerprint and nobody on the factory floor knows or cares which tool you used. If a manufacturer can't accept your files, the problem is in the file configuration and it's solvable in twenty minutes.
"There's no scripting or automation"
KiCad has a full Python scripting API. You can automate footprint generation, run DRC programmatically, manipulate netlists, generate custom reports, and write plugins that extend the UI. The codebase is open and the scripting surface is well documented. If you want a repeatable, scriptable hardware workflow, KiCad gives you more leverage than most closed commercial tools.
"Differential pairs and length matching don't work properly"
They work. KiCad supports interactive differential pair routing with configurable gap and width, and length tuning with accordion patterns. USB, Ethernet, and LVDS designs get done in KiCad routinely. There are nuances at higher speeds, which I'll come to, but the blanket claim is simply wrong.
"The UI is unusable coming from Altium"
Different, yes. Unusable, no. KiCad 7 and 8 made substantial improvements to canvas rendering, push-and-shove routing, and keyboard shortcuts. The transition takes a few weeks of muscle memory adjustment. Engineers who've made the switch aren't struggling after three months.
The Real Limitations: What KiCad Actually Can't Do
Constraint-managed high-speed design
This is the real one. KiCad has length matching and differential pair routing. What it doesn't have is a constraint-driven flow where you define electrical requirements, impedance targets, topology rules, propagation delay budgets, and the tool enforces them from schematic through to layout.
For DDR4 at modest speeds or PCIe Gen 2, an experienced engineer can manage this manually. It's more effort and more discipline. For DDR5, PCIe Gen 4 and above, or any design where timing margins are genuinely tight, the constraint management in Altium or Cadence is doing real engineering work. It's not a luxury at that point. Be honest with yourself about which category your designs sit in.
Centralised library governance for teams
A single engineer managing their own library has no significant problem. A team of four or five engineers enforcing part approval workflows and maintaining symbol, footprint, and BOM attribute consistency across projects will find that KiCad's infrastructure starts to ask something of them. It can be done with a shared Git repository and defined processes, but you're building and maintaining the governance layer yourself. Commercial platforms come with it already built.
ECAD/MCAD live collaboration
KiCad exports STEP, which is genuinely useful for enclosure design and clearance checks. What it doesn't offer is a live co-design environment. Altium's MCAD Co-designer keeps the PCB and mechanical model synchronised. If your EE and ME teams are iterating in parallel on a mechanically complex product, that tight loop has real value and KiCad doesn't offer it.
Design visibility for the rest of the team
KiCad is a desktop application. Anyone who isn't running it, your firmware engineer checking a pinout, your supply chain person cross-referencing a BOM, your CTO reviewing progress, is outside the loop unless someone remembers to export a PDF. That's a real gap and it gets worse as the team grows.
This is the problem CADPreview is built to solve. It connects directly to your KiCad project on GitHub and gives everyone a browser-based view of the design, the BOM, and the revision history. No KiCad licence required. No training required. It's not a full enterprise EDA collaboration platform. It's a focused solution to the visibility problem that comes with any desktop-native tool, at a cost that fits the purpose.
The Honest Summary
The limitations that actually matter come down to two: if you're doing serious high-speed design where constraint management does real work, KiCad is the wrong tool. If you need centralised library governance at scale, plan to build that infrastructure yourself. Everything else on the common objection list is either solvable, overstated, or hasn't been true for several versions.
Most hardware products don't sit in the constraint-managed high-speed category. Most hardware teams aren't large enough for the governance gap to be disqualifying. Which is exactly why, for most teams, KiCad is enough. And why it's worth being precise about what "enough" actually means, rather than letting reputation do the reasoning for you.
What's Next
The next piece in this series gets practical: how to build a complete £0 hardware toolchain, from schematic capture to manufacturer-ready files, using only free and open-source tools.
After that: version control for hardware. If you've never used Git for PCB design, it's less complicated than it sounds, and it solves problems that will otherwise cost you at the worst possible moment.
CADPreview is a web-based viewer for KiCad projects hosted on GitHub, built for teams who want design visibility without the overhead. It's in beta, which means it's improving fast, and your feedback shapes what it becomes.