Why I Started Logging Every Keyboard I've Ever Built
I've spent more time than I care to admit on spreadsheets and notebooks tracking switches, stems, housings, lubricants, and how they felt after different amounts of typing. A Comprehensive Mechanical Keyboard Logbook isn't some fancy software product. It's just a structured way to keep track of what you do so you don't forget why you did it three months later. Here's how I set mine up and what I actually use it for on a daily basis.
Building Your Comprehensive Mechanical Keyboard Logbook
Start simple. I use Google Sheets because it's free, portable, and easy to share if you want to trade notes with someone online. The columns that matter are: Switch name and brand. Full manufacturer name. Don't just write "Gateron." Write "Gateron Milky Yellow Pro 62g." The difference between a standard Milky Yellow and the Pro variant is enough to change how the keyboard feels, and you'll forget which one you used if you're not specific. Stem and housing material. This is something most people skip. POM, polycarbonate, nylon, PBT — it matters. POM stems stay lubed longer and don't dry out. Nylon stems tend to squeak if you don't lube them well. I learned this the hard way when I built a board with Kailh Box Jade switches that sounded like crinkling plastic after two weeks because I didn't note that the housing was polycarbonate and the stem was Nylon V2.
Lube type and amount. I use a brush, not a bath. THK 105 for stabilizers, Krytox 205g0 for springs and stems, and a light coat of Dielectric grease on contact points. Write down exactly what you used and roughly how much. "Some" is not a measurable quantity in a logbook. "One thin brush pass per spring coil" is. Spring weight. 45g, 50g, 62g, 67g — record it. Switches feel different on the same plate with different springs, and you'll want to know if a particular sound profile came from the switch or the spring. Plate material and thickness. Aluminum, brass, steel, FR4, polycarbonate. This is the single biggest factor in sound after the switches themselves. A 3mm aluminum plate with GF68 will sound drastically different from a 1.5mm FR4 plate on the same PCB with the same switches. Log it.
Get the Full Details
Case and foam configuration. I track every foam layer: top foam thickness and density, bottom foam, PCB foam, plate foam. Different foams absorb different frequencies. Closed cell foam kills high end. Open cell foam muffles low end. I once spent three evenings troubleshooting a "muddy" sound only to realize I'd swapped out the PE foam for a thicker sheet without updating my log, so I had no record of what was actually in the case. Date built. Not optional. Switches settle. Lubricants dry. You'll want to know if a later revision of the same switch tastes different because the formulation changed, or if your build just aged. Rating and notes. I use a simple 1 to 10 scale for sound, feel, and noise level, then add freeform notes. Sound is subjective but consistency across builds lets you compare. If you rate every board on the same scale, patterns emerge.
What Most People Get Wrong
The biggest mistake is logging only the successful builds. I used to skip entries for keyboards that felt mediocre or sounded bad. That was a blind spot. The worst sounding board I ever built was a Keychron Q1 with Novodots and no foam, and because I logged it with a solid explanation of why it sounded terrible, I avoided that combination on future builds. If you don't record failures, you'll repeat them. Another common error is not tracking mod results separately. If you take an existing keyboard and change just the switches, or just the foam, or just the plate, the log needs to reflect that as a modification, not a new build. Otherwise the data gets messy and you lose the ability to isolate variables. I started a separate section in my sheet for mods with the same columns but an added column for what changed. It takes about ten seconds per entry and makes analysis much cleaner. There's also the issue of batch variance. Two batches of the same switch from the same factory can feel different. I've seen this with Gateron Milky Yellows and Akko Lavender Pinks. When a batch feels off, note the lot number or supplier if you have it. It saves you from throwing away a switch you actually like just because one bad batch got mixed in.
A Practical Edge Case I Hit
Last year I rebuilt a custom 65 percent with TGR Amanoa switches. I lubed the stems with Krytox 205g0 using a brush method. Everything felt fine on day one. By week three, the switches were sounding scratchy again on the downstroke. I checked my log and realized I hadn't recorded the lubing technique, only the lubricant name. I went back through my notes, realized I'd used a very light coat, and the issue was simply insufficient lube on the stem rails, not a bad batch. I re-lubed with a heavier application and the scratchiness went away. If I'd just written "Krytox 205g0, switched out" without the technique detail, I might have blamed the switches and sold them for something else. This is exactly why the Comprehensive Mechanical Keyboard Logbook needs to capture process details, not just parts lists. The difference between a great build and a frustrating one is often a missing adjective in a note column.
How Long It Actually Takes
Initial setup of the spreadsheet takes about twenty minutes. Populating it as you build takes maybe five to ten minutes per keyboard. The real time savings show up when you're troubleshooting. Without a logbook, diagnosing a sound issue means disassembling the board, checking each component, and making educated guesses. With a logbook, you pull up the entry, see the foam configuration and plate material, and you know within five minutes whether the problem is likely the foam or the plate or the switch. For someone building two or more keyboards a month, a Comprehensive Mechanical Keyboard Logbook cuts diagnostic time from hours to minutes and prevents you from repeating mistakes you thought you'd already solved.
Alternatives If Spreadsheets Feel Like Too Much
I've seen people use Notion databases, Obsidian notes, or even physical notebooks. Notion is fine if you prefer relational databases and tagging. Obsidian works well if you want linking between entries so you can jump from a switch page to all the boards it appeared in. Physical notebooks are valid too, but searchability drops to zero when you need to find a specific combination six months later. I'd recommend a spreadsheet as the baseline and moving to a more complex system only if you hit limits with basic filtering. One thing I should be honest about: a logbook does nothing for your typing feel or sound on its own. It's a tracking tool, not a solution. If your keyboard sounds bad, the logbook won't fix it. It just helps you figure out what to change faster. If you're looking for actual modification guides, there are plenty of threads on GHKB and Discord servers that cover lubing techniques, tape mods, and foam placement in far more detail than I'm going to here. Just start logging. Keep it boring. The value comes from consistency, not complexity.
