The History of Cue2Keys: From Development Start to Initial Sales (Part 1)
Table of Contents
- Top
- Encounter With DIY Keyboards, Getting Started
- Concept Design
- Surveying Existing Keyboards
- Target Goal
- Architectural Foundations and Technical Elements
- The Keyboard as a System
- Discovering modulo and I2C
- Pros and Cons of the Full Modular Approach
- Current Architecture
- Case Design Philosophy
- Design Concept
- Sales-related
- Managing Module Production Quantities
- Online and Offline Sales
- Packaging
- Summary
Cue2Keys is a DIY keyboard that I developed for a little over a year from early 2024 to March 2025 and launched for sale. Development is ongoing, but as a milestone I decided to document the history up to the first sales.
In this series, I share in detail the trial-and-error process from prototype to product. The article got long, so I split it into two parts: in the first part I summarize motivations and overarching concepts, and in the second part I describe the evolution of each module and technical details.
Encounter With DIY Keyboards, Getting Started
First, since this is my first DIY keyboard, I’ll record what motivated me to start building.
I’d always been interested in good keyboards but hadn’t pursued them. Before starting this project, I had long been satisfied using HHKB, but I wanted to try the oft-mentioned split style. I borrowed an ErgoDox EZ from someone and gave it a shot.
Once I actually used it, I was impressed by how easy column-stagger feels to type on, the high degree of customizability, and the convenience of layers. What stood out most was how many keys are placed around the thumbs. Thinking it through, I realized I had hardly been utilizing my thumbs—despite their large range of motion—on conventional keyboards[1]. Height adjustment was also easy, and the included palm rest matched the height perfectly, so it felt very natural in the hands.
Although I didn’t have any major complaints with the ErgoDox, after using it for a while some points started to bother me: I wanted to split the long, narrow thumb keys; there were many keys I couldn’t make good use of; I wanted to shift key positions forward by column; the mapping required a dedicated app which hurt usability; and on the minor side, the LEDs indicating layers were too bright[2].
I had a vague idea that there was a world of DIY keyboards starting with the ErgoDox, but didn’t know the details. Following the path many take, I visited Yusha Kobo, where I encountered many attractive keyboards. After a while of searching and buying various boards, it dawned on me: “Why don’t I just make one myself?” A naïve thought indeed. And thus I began my descent into the DIY keyboard swamp.
Concept Design
Closely tied to my motivation for building, the current concept for Cue2Keys is a keyboard that is “flexible and dynamic.” Here I’ll record how I arrived at this concept.
Surveying Existing Keyboards
As mentioned, I was looking for keyboards that let me add a trackball later or finely adjust key positions. I covered this in detail in my previous book, “An Introduction to DIY Keyboards: How to Make a Modular Keyboard”, so I’ll skip the nitty-gritty, but there are keyboards in the world that implement such functionality by various means. From my research, I saw some where the entire thumb cluster is a replaceable module, but very few where you can freely change the number and positions of non-thumb keys.
Target Goal
People immersed in the DIY swamp probably envision their ideal keyboard and create day by day. That’s the “goal” of the project. For me, “a keyboard I can customize as I like” came to mind first. At a glance, it might seem like a general-purpose product for a wide audience, but it emerged as something I wanted for my own use.
Looking back, I noticed that what I want from a keyboard changes over time. When I was trying different logical layouts, sometimes I needed more keys, sometimes they were in the way—lots of patterns. I’m currently in a phase of trying column-stagger, but I’ll probably want to explore other layouts as well.
On a shorter time scale, it also varies by task. The optimal keyboard shape differs between programming and playing Factorio. This is especially pronounced for one-handed devices as widely known. Sometimes having a trackball is convenient; other times I want more keys there instead.
The apps I use and my desk setup all change with time—everything is impermanent.
Amid that, I came to believe flexibility—freedom from a single fixed shape—is crucial. I decided to aim for a keyboard where I can place the functions I need, when I need them, where I want. Moreover, I believed it important that such customization be dynamic and easy. If I can’t change things while actually using it, adjustment itself becomes a chore.
Taking these into account, I settled on the concept of a keyboard that is “flexible and dynamic.” Based on this concept, I’ve been working on development day by day from the beginning to now.
Architectural Foundations and Technical Elements
From here, I’ll get into development details.
The Keyboard as a System
Looking at keyboards anew, you can see that user input passes through multiple components before reaching the PC.
When a user presses a key, the key switch moves (for mechanical), conductivity occurs -> the switch component connects to a hot-swap socket, etc. -> PCB traces -> MCU pins -> the firmware reads it and processes it. Each part functions as a component specialized for its own processing, and by collaborating through fixed interfaces, they make up a single keyboard system. If you adhere to these interfaces, you can insert other components along the way and alter processing. In hardware, many of these are standardized. Non-key parts common in DIY keyboards—like trackballs, rotary encoders, and displays—can be understood in the same way. In software architecture terms, Service-Oriented Architecture (SOA) might be a close analogy.
Usually for hardware design and cost reasons, keyboards are treated as monolithic systems. But I thought that if I physically separated them, I could freely add parts or adjust positions. In other words, I aimed to design each interface as an independent module and create a system that can be freely combined. I hardly saw any keyboards where the keys themselves are modular at 60% and above, so I took the liberty of calling it a “full modular approach”[3].
Discovering modulo and I2C
Researching along these lines led me to modulo, proposed years ago by biacco. Unfortunately, development seems to have stopped recently, but the book describes a design where a “pendant” (the brain) connects with other modules via I2C, which looked directly applicable.
I was a beginner at electronics, so this was my first exposure to I2C, and I was amazed by how convenient it is. This may be obvious to those experienced in circuit design, but I had thought “don’t you need one pin per device?” and was about to stumble at the very beginning. With I2C, however, you can run just two data lines, share them across devices, and connect multiple devices flexibly. It even supports hot-plug, letting you handle devices as easily as with USB. It was exactly the connection method I was looking for.
So in early 2024 I spent my time validating I2C. Back then I used a Pro Micro and tried various tests. I remember being relieved when I confirmed that it worked fine even with multiple key modules connected.
Pros and Cons of the Full Modular Approach
The biggest advantages are freedom in number and placement, and dynamic changes. With conventional keyboards you can’t change the physical layout set by the manufacturer, but with a full modular approach, users can search for an optimal shape that fits their hand size and environment. I’ve gotten used to column-stagger, but I hear many around me want row-stagger. Grid layouts and Alice layouts (not supported currently) are also popular. I often hear requests like “I want the middle finger column a bit higher.” If you can freely change such placement and explore what fits you while keeping costs down, that would be great.
On the other hand, there are big downsides to making modules independent. The complexity of connections and cost increases are major problems[4]. And because you can’t leverage existing knowledge in many places, verification and development time certainly increases. Fundamentally, since there are more parts to connect components, manufacturing cost clearly goes up. In reality, most of Cue2Keys’ development time was spent on technical verification. Just getting it to work properly was all I could manage, and I kind of ran out of time.
It was so hard that I can’t recommend this approach at all for a first DIY keyboard. If you plan to sell it too, there’s even more to do and it’s tough. That said, from a learning perspective it’s extremely useful. Hardware requires circuit design from scratch, and typical firmware (QMK or ZMK) won’t work as-is, so you need to modify it. On top of that, you have to design the case from scratch[5]. Beyond functionality, there were challenges like how to physically secure modules together and ensure overall stability. I’ll cover these in detail in the second part on module development.
With this setup, if you match interfaces, you can easily connect compatible products to expand the system. If more developers join, both users and developers benefit from accumulated knowledge—in other words, it can scale. But it’s tough in practice right now.
Current Architecture
In today’s Cue2Keys, the key modules and knob connect to the pendant via I2C. The hub has no ICs; it’s simply an I2C relay point with connectors. By preparing connectors as shown, you can make them recognized as I2C devices. Note that the mouse sensor uses 3-wire SPI, so it connects directly to the pendant (details in part 2).
I2C connector pinout
I2C is a short-distance communication standard, so it has no prescribed countermeasures for attenuation. Since the speed is relatively slow (the 400 kbit/s mode), you don’t have to overthink it, but wiring length and cable quality do have some effect. In testing, I performed stress tests by daisy-chaining modules to the limit and using extension cables. As a result, by using relatively strong pull-up resistors, it worked fine for normal use and matched the I2C spec well. Being wired, I don’t need to worry about power saving, which also contributes to a simple architecture. Currently, due to IC and connector constraints the limit is 160 keys, but the design can support more.
Case Design Philosophy
With a full modular, base-mounted approach, each module needs an appropriate case. I vaguely knew it would be hard, but it turned out to be very challenging—one of the toughest parts of development. I’ll leave details for part 2 and record the overall design philosophy here.
With Cue2Keys I tried to avoid screws where possible and lean on 3D-printed design. There are several reasons.
First, screws, nuts, and other parts increase and assembly becomes complex. Tightening screws is simple, but when there are hundreds it’s painful, and they might come loose for some reason.
Second is cost. Do you know how much screws cost? I didn’t—I assumed since they’re everywhere, they’re like 0.1 yen each. I was shocked to learn that common stainless screws cost more than 5 yen each. Of course, bulk purchase will likely get a discount, but for only a few hundred, they’re fairly expensive.
Third, 3D printers can make many shapes. I didn’t initially think I could secure things without screws, but with trial and error it worked better than expected, and I saw a lot of potential in 3D printing. As alternatives to screws, I use the key switches themselves to secure the key modules, and for other modules I separate base and lid and secure them with tabs. Balancing tab durability and sufficient retention is hard and still under adjustment, but it’s an interesting area with lots of tricks.
The trackball module requires screws and washers due to bearing constraints, but for other modules I manage with tabs. Each ended up with different tab shapes; if you’re interested, it might be fun to examine the case you have.
I mainly printed cases with a Bambu Lab A1 mini, and used JLC3DP when I needed resin printing precision. 3D printers have become an indispensable tool, and I plan to keep leveraging them to create various cases.
Design Concept
As a gadget connected to a PC, many keyboard designs go for a cool, stylish direction. Since Cue2Keys is a system where you combine blocks, I looked for a name and design concept aligned with that. I added a toy-like playfulness, with each module being small and roundish, which led to the current soft, cute direction.
I also created module characters to match. The main character, Yuuichi, was born quite early, and I’ve found it useful for business cards and announcements. I’ve only drawn the operator modules so far, but I’d like to complete all modules eventually. Each takes about an hour to draw, so it’s a matter of prioritization.
For the website, I first made a rough mock earlier in development and left it at “I’ll sort it out before launch.” Then I was overwhelmed with technical verification and ended up with no time for design—crunch time. For what I did from there, see the previous article.
For now, I haven’t been able to put much of the concept into the product itself. I wanted to unify the look starting with colors, add easter eggs to silkscreens on PCBs, etc., but I simply didn’t have time. If I wait to tackle this until the functionality is stable, I can’t make it in time at all, so I now think it’s important to untangle task dependencies and proceed in parallel.
Sales-related
Managing Module Production Quantities
What happens when the number of module types increases? Quantity management becomes difficult. For example, the Starter Set DX consists of keys, hub, pendant, knob, and trackball, and you can’t make the set unless you have all modules in stock. On the other hand, if I allocate everything to sets, I can’t offer individual modules.
I tried to plan per-module production quantities and, when timing allowed, break sets to reallocate stock to individual module sales, but despite my efforts, inventory skew between modules is quite severe. I half-gave up, seeing it as an eternal challenge of modular products. Going forward, I’m considering combining made-to-order with faster manufacturing cycles for modules.
Online and Offline Sales
After the first sales at Keyket 2025, I’m now selling online via Booth. Booth is a handy service with all the basic features including anonymous shipping, easy to use, and with relatively low fees (which just went up, by the way). There are parts where it falls short, but I don’t see a perfect alternative among other online stores, and its convenience helps a lot.
I’m also consigning sales with the familiar Yusha Kobo (product page). A physical store where I can exhibit the product is extremely valuable, and I’m truly grateful from the seller’s perspective. Exhibits depend on inventory, so it’s timing-dependent, but if the timing works out, I’d be happy if you try it in-store.
Packaging
For Cue2Keys sets, I emphasize being usable out of the box. In other words, take it out of the box, plug it into your PC, and it works. To be honest, assembly and packing are a lot of work, but because there are many inter-module connections and it’s hard to get everything into a correct state, and because customization is difficult unless you start from a working state, I settled on this format.
Also, Cue2Keys key modules come with key switches included. You don’t see this much in DIY keyboards, and it wasn’t my original intention. I actually use them as fixtures; without them, the PCB slides out of the case. Furthermore, I need to insert switches for operation checks anyway, so I decided to include them so they can be used as-is. Since these are temporary switches, I recommend gradually replacing them with ones you prefer.
For the box, after trial and error I currently use a B6-sized cardboard box that just barely fits the DX set. I also wanted to create branded packaging with a logo, but it turned out much harder than I imagined.
I need to fix the size, but the module shapes themselves were changing during development, and the product outline differs depending on which modules you combine, so the orderable timing never came. Cost is also a big issue. It was easy to miss while constantly receiving boxes from major e-commerce sites, but I learned that cardboard is more expensive than I thought. I assumed it was single-digit yen each, but even the small size above costs more than 80 yen per box. Custom-printed or custom-sized cosmetic boxes are several times more expensive, with a minimum order of 100+ units, which inevitably pushes up the product price. So for the time being, I’ll likely stick with simple packaging.
Since I couldn’t make a cosmetic box, I made masking tape instead. I tried making it for packing; it’s a larger 5 cm size than usual. Adding a small strip to the box gives it a little fun vibe.
Summary
I recorded the history of Cue2Keys from the start of development to just after the first sales (part 1).
In the second part, I’ll introduce the concrete evolution and technical details of each module.
While using thumbs is common even in Beatmania IIDX, I hadn’t connected that to keyboards ↩︎
I put masking tape over them to dim the brightness ↩︎
A term I only ever hear for PC power supplies ↩︎
Frequently heard when discussing microservice architecture in system development ↩︎
The book mentioned earlier also follows this approach to build a modular keyboard ↩︎
