Why I built Cirkit (and how I actually use it)
By Nick · 6 min read
Hi, I'm Nick, an electrical engineer. A big chunk of my job isn't designing circuits. It's helping other people understand them: an apps engineer with a tough customer question, or a test technician staring at a failed unit that won't power up.
The people I work with are great at what they do, but most of them aren't design engineers, and a stack of multi-board schematics can be intimidating even when you know your way around a bench. So they come to me. A lot. And the thing I kept running into is that even good documentation doesn't fix this. The stuff we don't write down, because “everyone knows that,” is exactly the stuff the next person doesn't know. Why does that test point read 1.85 V? Which board does FAULT_N end up on? What did we try last time this rail drooped? That knowledge lives in a few people's heads, and it walks out the door at 5 pm.
So I built Cirkit, a tool that turns your static schematic PDFs into interactive documentation anyone on the team can follow, without ever leaving the PDF viewer. Here's how I actually use each part of it.
Notes right on the schematic
It started with the questions I got asked over and over. Every few months someone would ask what a particular corner of a board was for, and I'd explain it all over again. Now, whenever I explain something once, I drop a note right on the part, net or region it's about, like “Split CAN termination: remove R30/R31 if this board isn't at the end of the bus.” I'll often attach a photo too: a bodge wire, a scope capture, or a picture of the real board. Every note is searchable, so the next person who wonders about the CAN bus types “CAN” and finds the answer pinned to the exact spot it's about, instead of finding me.
Signal traces you can record and replay
Notes take care of the one-off questions, but the conversation I used to have most was a lot longer. A fault signal might start at a current-sense amp on one page, run through the protection logic on another, cross onto a different board, and end at an MCU pin and an LED. Walking someone through that used to sound like “OK, now go to page 4… no, the other connector…” Now I record the path once, step by step, across pages and even across separate board schematics, with a short comment on each step. Anyone can press Play and Cirkit walks them through it, jumping to each step on the right page. It's like having me sit next to them, except I don't have to, and it's the feature new hires and interns get the most out of. It's also the one I'm proudest of.
BOM data on every component
Following a signal is one thing, but people also need to know what they're looking at along the way, and that used to mean lining up the BOM spreadsheet with the drawing. Someone wants to know what U1 is, so they open the spreadsheet, search for the designator, and squint back at the PDF. With Cirkit I import the BOM once and every row lands on its reference designator. Hover over U1 and it tells you it's a TPS54360 buck converter, with the MPN, value and package right there. It sounds small, but it takes away a lot of tab-switching, and it means everything else in Cirkit knows exactly what each part is too.
An AI that actually reads your board
That last part matters a lot for the AI built into Cirkit, because sometimes people just want to ask a question in plain English. It isn't a blank chat box guessing at your design. It sees the page you're on, your BOM and your team's notes, and if you box an area, it zooms in on just that part of the circuit. It can also read the text on every page of every schematic in the project, which is where it gets really useful for me. I can ask it to make a table of all the power rails, list every connector, or tell me where RESET_N shows up. Every rail or net in the answer comes with a little link, and clicking it takes you straight to that spot on the schematic, highlighted. That's a big time-saver when you're new to a design and don't know where anything is yet.
Datasheets from DigiKey and Mouser in one click
Whether the question goes to the AI or to me, it often ends at a part's pinout or ratings, which used to mean googling the part number and hunting for the right PDF, every single time. Now I highlight the part number on the schematic and look it up without leaving Cirkit. It searches DigiKey, falls back to Mouser, and one click attaches the datasheet to the part. From then on anyone on the project opens it straight from the schematic, and every other part with the same MPN picks it up automatically.
Measurements where they were taken
When a unit fails, troubleshooting usually comes down to comparing readings against a good one, and those good readings tend to live in someone's notebook from bring-up. So I log measurements right where they were taken, grouped by the test condition: “Bring-up rev A: 1.85 V at 3 A” on TP3, “Thermal soak: 4.99 V at 70 °C” on the 5 V rail. A technician with a meter on a bad board can check their number against what a good board read, without waiting for me to dig up my notes.
Issues that remember what was tried
The question I hate most is “didn't we see this before?”, because the answer is usually buried in an email thread from months ago that only two people were on. So now, when a debug thread starts, I CC our workspace's email bot. Cirkit files the thread into the right project as an issue and keeps a dated summary of the problem and everything that was tried, and by whom: “Oct 5, Nick: added 22 µF at the U4 output; droop improved to 3.1 V.” As more emails come in, the summary keeps growing, and I can open issues by hand too. The next time a rail droops on that board, the technician doesn't have to ask around. The whole history is right there next to the schematic.
Equations that use real part values
Troubleshooting also leads to the “is this right?” questions. Is 5.02 V on the output OK? Answering that used to mean someone re-deriving the feedback divider from scratch. Now I write the equation once, the way it looks in a textbook, something like Vout = 0.8 V × (1 + R1/R2), and Cirkit pulls R1 and R2 straight from the BOM and shows the result, 5.00 V, right on the schematic. Change an input and it updates. There's a logic mode too, so for a comparator or a gate you can see exactly when a trip signal goes HIGH.
Sketching a fix
When something does need to change, I used to propose it with a marked-up screenshot in an email thread that nobody could find a week later. Now I sketch the change right over the PDF (a filter cap, a pull-down, even a whole IC), write down why, and let the team comment on it. When it's ready, I export a marked-up PDF to take into the design review.
Sharing with the people who need it
None of this helps if the right people can't see it, and half of them aren't on the design team, or even in the company. So I invite teammates into a shared workspace, where viewers are free. For a customer or a supplier, I send a view-only link that expires after 30 days. No account needed, and they can still browse the notes, the BOM, the datasheets and the trace playback.
So… did it work?
For my team, it did. People find answers in the schematic instead of in my inbox, new folks get up to speed much faster, and I spend a lot less time repeating myself, which was the whole point.
Now I want to find out whether it helps other engineers too. Cirkit is in early access and free to try, and the quickest way to see it is the live demo: a real board, no sign-up, and a guided tour of everything above.
If you give it a spin, I'd genuinely love to hear what works, what doesn't, and what's missing. Tell me here.
— Nick