Building a System That Actually Sticks
Most people approach custom keycap management the same way they approach a hardware project - they buy a spreadsheet, fill it with data, and hope it stays useful. It doesn't. The problem isn't the tool. It's that keycap orders don't follow linear timelines and your data needs to survive three different states: pre-order limbo, manufacturing wait, and post-delivery integration. I spent eight months trying to make Google Sheets work as a Logbook For Custom Keycaps Comprehensive. It collapsed under its own complexity around month four when I had seventeen pending orders across three manufacturers, two sets in transit, and six already sitting on my desk. The spreadsheet became a graveyard of half-updated rows and abandoned formulas.
The Core Problem Nobody Talks About
Custom keycap tracking fails because it's not really a database problem. It's a state-machine problem. Each keycap set goes through distinct phases, and each phase requires different information. Pre-order phase needs manufacturer contact, deposit amount, expected ship date, and profile notes. Manufacturing phase tracks production updates, QC photos, and shipping changes. Post-delivery phase logs unboxing impressions, keycap profile measurements, compatibility results, and final cost including shipping and taxes. Most logbooks treat all phases the same. That's why they break. My setup now uses a tab-based structure where each tab represents a lifecycle stage. I keep five tabs active: Dashboard, Incoming, In-Production, Shipped, and Completed. The Dashboard shows current priorities. Incoming tracks pre-orders and deposits. In-Production monitors manufacturing updates. Shipped handles logistics. Completed stores everything after delivery plus review data.
What Actually Goes in the Logbook
Here's the minimum viable dataset. Anything less and you'll forget critical details. Anything more and you'll stop maintaining it. Order Identifier - Use a consistent format. I use YYYYMMDD followed by manufacturer initials and a sequential number. So 20240315GMK001 means GMK pre-order number one from March 15, 2024. This eliminates confusion when you have multiple orders from the same manufacturer across different years. Manufacturer and Product Code - Not just the brand name. GMK doesn't tell you which profile you're getting unless you check. Some sets come in both ABS and PBT from the same manufacturer. Write down the exact SKU or product code if available, plus the material type and profile designation.
Financial Trail - Deposit amount, balance due, currency, payment method, and total landed cost. The last one is critical. Your $80 keycap set might cost $112 after shipping, customs, and currency conversion. If you don't track landed cost, your budget planning is wrong. Date Fields That Matter - Order date, deposit date, estimated ship date, actual ship date, customs clearance date, and delivery date. Estimated dates will lie to you. I learned this the hard way when a set estimated for April showed up in August. Keep the original estimate for comparison, but track actuals separately. Physical Notes - Profile height at the spacebar, keycap thickness if specified, file type (stabilizer or wire), and any compatibility notes. I once bought a set that looked standard but used non-standard file spacing. It sat unused for six months before I realized why my stabilizers weren't fitting properly.
A Specific Edge Case That Broke My System
Here's the problem I hit that forced me to redesign everything. I ordered two sets from the same manufacturer in the same month. Both had similar product codes. Both shipped from the same warehouse in Germany. One arrived with delayed customs clearance that added eleven days. The tracking number for the delayed set got mixed into my spreadsheet with the on-time set, and I couldn't tell them apart for three weeks. The fix was simple but easy to miss. I started using a dual-identifier system. Each entry gets both the manufacturer's reference code AND a unique internal ID that I generate myself. When tracking gets confusing, the internal ID cuts through the noise. I also started including the order confirmation page screenshot in the same folder as my log entry. Not embedded - just linked. Takes three seconds and saves hours of confusion later.
Building the Actual Structure
You can use a spreadsheet. You can use Notion. You can useObsidian with dataview. The tool doesn't matter. The structure does. Every row is one keycap set. Every column is a data field. Don't create separate rows for individual keys. The unit of tracking is the complete set, not the keycap. If you track per-key, you'll drown in data and gain nothing. Set up conditional formatting that colors rows based on status. Orange for In-Production. Yellow for Shipped. Green for Completed. Gray for Cancelled. This lets you scan ten rows and know exactly which orders need attention within five seconds.
Use data validation for status fields. Don't let yourself type "in production" in one row and "producing" in another. These become invisible inconsistencies that compound over time. Pick five status values and stick to them. Calculate landed cost automatically. Formula should be: deposit + balance + shipping + customs + tax + currency conversion adjustment. If your spreadsheet can't show you the real total cost at a glance, it's not doing its job.
Common Pitfalls That Waste Time
The biggest mistake I see people make is over-engineering the logbook. They add fields for things that never change. Keycap font. Switch type compatibility. Desk mat color coordination. These belong in your head or a separate inspiration folder, not in the tracking system. Every extra field is friction. Friction kills maintenance. Another mistake is not linking to source material. You'll forget which thread you found the manufacturer's update on. You'll lose the Discord message where someone confirmed the file spacing. Link directly to the relevant post, thread, or manufacturer page. Put the link in the row. It takes two seconds and prevents three hours of digging later. Third mistake: not backing up the logbook. I lost four months of tracking data when my Google account got flagged and temporarily suspended. I had no local copy. All those landed cost calculations and compatibility notes gone. Export your logbook to CSV weekly. Store it somewhere that isn't tied to one platform.
When a Logbook For Custom Keycaps Comprehensive Stops Being Useful
Real talk about limitations. This system works well until you cross roughly forty active orders. At that point, the spreadsheet becomes slow and unwieldy. The tab-switching slows you down. Conditional formatting creates visual noise. You start missing entries because there's too much on screen. If you're past that point, switch to a proper database application. Notion, Airtable, or even a local SQLite database with a simple front-end. The structure stays the same. The tool just scales better. But don't make this switch prematurely. Most people never reach forty simultaneous orders. I knew a collector who had twelve hundred keycap sets and still used a spreadsheet because the organization was cleaner than any database he'd tried. The logbook also struggles with highly variable lead times. If you're ordering from manufacturers who communicate poorly or change schedules weekly, your estimated dates become meaningless noise. I handle this by removing the "estimated ship date" field entirely and replacing it with a "last manufacturer update" field. That way I'm tracking actual communication, not hopeful guesses.
Getting Started Without Overthinking It
Don't build the perfect system first. Build a functional one today and adjust as you go. Start with seven columns: Internal ID, Manufacturer, Product Name, Status, Total Cost, Order Date, Expected Delivery. Add fields only when you hit a problem that this setup doesn't solve. Copy this structure into whatever tool you're comfortable with. I'll share mine if anyone wants to see the exact layout. The specific spreadsheet formulas don't matter as much as the underlying logic. You can adapt the logic to any platform. The goal isn't perfection. The goal is having data you can trust when you need it six months from now. When you're wondering whether that set you ordered in January was actually PBT or ABS. When you need to prove a deposit to get a refund. When you're comparing landed costs across three different manufacturers to decide your next purchase.
Build simple. Track consistently. Adjust when it breaks. That's how you end up with something useful instead of something abandoned.
