Tracking Your Builds
Most people who get into mechanical keyboards end up with too many boards to remember. You buy a prebuilt, modify it with a lubed set of switches, then move on to a new project and suddenly you can't recall what stem type you used on the middle cluster or whether the plate was aluminum or polycarbonate. Keeping notes solves this. A mechanical keyboard journal is just a structured log of every board you own or work on, with enough detail that you can reproduce a sound or feel months later. I started mine as a Google Sheet because that is the path of least resistance. You can use a notebook, but trying to search through handwriting when you need to know which stabilizerMod you did on the spacebar six months ago is miserable. Start with columns for date acquired, brand, model, case material, plate material, plate thickness, switch type and brand, switch lubricant if any, switch spring weight, stabilizer type, stabilizer setup, keycap profile and material, firmware (if applicable), sound profile notes, typing feel notes, and cost. That last column matters more than people admit. The actual process of filling this out takes maybe ten minutes per build once you have the template locked in. I usually do it on the same evening I finish testing the board. Memory fades fast. I remember the first time I skipped it and came back two weeks later trying to recreate a feel I liked. I had no idea if I used 3M blue tape or O-ring dampening inside the case. I ended up buying tape, opening the board, and discovering I had already put foam in there. That mistake cost me about forty-five minutes and a trip to the store.
What Actually Matters In The Log
Beginners tend to over-track or under-track. They either write "nice thocky board" with zero technical detail, which is useless for replication, or they log every single screw type and ignore the things that change the outcome. The meaningful variables are plate material and thickness, foam and tape layout, switch specs, stabilizer treatment, and keycap profile. Those five things drive ninety percent of the variation in sound and feel between two otherwise similar boards. Case material matters less than most people think. Two polycarbonate cases from different manufacturers will sound closer to each other than a polycarbonate plate and an aluminum plate on the same case. Do not waste energy obsessing over whether the case is ABS or PC when the plate choice will overshadow it entirely. Write it down anyway for completeness, but prioritize the plate and the dampening layers. Switch lubricant is another area where beginners waste time logging irrelevant details. Record the lube brand and viscosity, yes, but also note the technique. Did you dip the stems or coat the housings? A full housing lube changes the sound noticeably compared to stem-only lube, and that distinction is easy to forget. I once wrote "lubed" on three separate entries and could not tell which boards got full housing treatment versus minimal stem lube until I tested them side by side. Now I specify the method in the notes column.
Sound Logging Without Getting Obscure
Audio recording your keyboard is useful but easy to mess up. Phone mics compress audio badly and pick up room noise. If you want actual reference recordings, get a small USB condenser mic and record in a carpeted room with minimal echo. Keep it simple. One take per board is enough. Label the file with the date and board name immediately. I once had forty-seven audio files named "recording1," "recording2," and so on. It took me twenty minutes just to match them to my spreadsheet entries. For most people, written sound descriptors are sufficient if you standardize your language. Pick a small set of terms and stick to them: thock, clack, clacky, ping, dull, deep, sharp, bassy, high-pitched. Using consistent vocabulary means you can scan your own notes later and make comparisons. Writing "sounds nice" is not a descriptor. It is a feeling, and feelings do not help you replicate a result.
Get the Full Details
Stabilizer Tracking Is Where People Mess Up
Stabilizers are the single most inconsistent part of any build. You can use the same switch brand across five boards and only the spacebar and shift keys will sound different because of how you treated the stabs. Log stabilizer brand, wire gauge if relevant, whether you used tubing, the type of lubes or tapes applied, and whether you did a band-aid mod or a switch modification. These details matter at the component level. I learned this the hard way on a GMK-style project. I had logged that I lubed the stabilizers but did not record that I also ran keychains through the washers. When I tried to reproduce the layout on a second board, the spacebar sounded buzzy because I had forgotten the keychain mod entirely. I spent an hour debugging what I thought was a lube issue before realizing the modulation setup was different. Now I include a dedicated stabilizer sub-section in my entries with checkboxes for each treatment type.
Cost Tracking That Does Not Drive You Crazy
Financial tracking in a keyboard journal does not need to be an accounting exercise. You do not need to track shipping costs per item or calculate tax deductions. Record the total board cost including all mods at the time of completion. That number tells you what a finished build actually cost you, which is the only number that matters when you are deciding whether to sell, upgrade, or compare against another board. Resale value tracking is optional but helpful. If you sell a board, record the resale price and the difference from your total spend. Over time this reveals which mods actually preserve value and which ones are pure waste. Custom lubed switches rarely add resale value. Premium keycaps do, slightly. Plate swaps usually do not, unless the original plate was notably cheaper material.
Format Options And Their Tradeoffs
Spreadsheets are the default for a reason. They sort, filter, and calculate. The downside is that they are rigid. Adding a new column later is easy, but embedding photos or audio files is clumsy. Google Sheets allows image insertion, but it bloats the file. Apple Numbers handles media better. If you want a visual journal with photos of each build, Notion or Obsidian works fine, but you lose the quick filtering that makes a spreadsheet useful for comparison. Here is a practical rule I follow: use a spreadsheet for the core data and keep a separate folder of labeled photos. Do not try to marry them in one tool unless your workflow demands it. A well-organized Google Drive folder with thumbnails named by date and board will serve you better than a bloated database you struggle to update.
When A Journal Stops Being Useful
If you build fewer than three boards a year, a full spreadsheet is overkill. A simple document with dated entries works just as well. The maintenance burden of a detailed system will push you to abandon it if the effort outweighs the benefit. Similarly, if you mostly buy prebuilt boards and do not modify them, the journal becomes a purchase log rather than a technical reference. There is nothing wrong with that, but adjust the columns to match what you actually do. The biggest failure mode I see is inconsistency. People start strong, log fifteen builds with complete detail, then skip entries for three months because the system feels like homework. Once the habit breaks, the entire log loses value because the gaps make comparison impossible. Set a minimum viable standard. If you cannot fill every column, at least log plate material, switch type, and stabilizer treatment. Anything less than that and you are better off not logging at all. A word of caution on the data itself. People remember their favorite builds inaccurately. You will convince yourself a board sounded deeper or felt lighter than it actually did, especially if you liked it aesthetically. Periodic re-testing after a break of six months or more will reveal these biases. I found one of my favorite-sounding boards rated significantly lower when I re-evaluated it fresh, and the difference was entirely in the foam layout I had misremembered. The journal caught the error because it recorded what I actually did, not what I thought I did.
Start simple. Fill it out immediately after each build. Stick to standard terms. Ignore perfection. The goal is reference, not documentation for its own sake.
