History of Cue2Keys: From Development Start to Post-Launch (Part 1)

"Cue2Keys" is a custom keyboard that I developed over more than a year from early 2024 to March 2025, when I started selling it. Development continues today, but as a milestone, I've decided to record the development history up to the initial launch.

https://cue2keys.esplo.net/

This article series provides a detailed account of the trial-and-error process from prototype to product version. Since the article became quite long, I've split it into two parts. Part 1 summarizes the overall story including motivation and concepts, while Part 2 covers the evolution and technical details of each module.

https://www.esplo.net/en/posts/2025/08/cue2keys_history_2

First Encounter with Custom Keyboards and Starting Development

First, let me record my motivation for starting to build my first custom keyboard.

I was interested in good keyboards but didn't pursue them too deeply and went about my daily life. Before starting development, I had been using HHKB for a long time and was satisfied with it, but I wanted to try the split-type keyboards I often heard about. So I borrowed an ErgoDox EZ from someone who owned one and decided to try it out.

When I actually used it, I was impressed by the ease of typing with column stagger, the high customizability, and the convenience of layer functions. What was particularly impressive was having many keys arranged around the thumb area. Looking back, I realized that previous keyboards had barely utilized the wide range of motion of the thumbs^[1]. Also, height adjustment was easy, and the included palm rest fit perfectly in height, making it comfortable for my hands.

While I had no particular complaints about the ErgoDox, after using it for a while, several concerns emerged. I wanted to split the long thumb keys, there were many keys I couldn't utilize effectively. Also, I wanted to shift key positions forward by columns, the mapping required dedicated software which was somewhat inconvenient to use, and minor issues like the layer display LEDs being too bright^[2].

I somewhat knew that there was a world of custom keyboards including ErgoDox, but I didn't know the details. So, like many people who follow the same path, I visited Yushakobo and encountered various attractive keyboards. For a while, I searched for and purchased various keyboards, but before I knew it, the overly naive thought of "Why don't I just make one myself?" came to mind. This is how I began to sink into the custom keyboard rabbit hole.

Concept Design

Closely related to my motivation for wanting to build a custom keyboard, the current concept of Cue2Keys is a "flexible and dynamic" keyboard. Let me record how I arrived at this concept.

Research on Existing Keyboards

As mentioned earlier, I was looking for a keyboard where I could add a trackball later or make fine adjustments to key positions. As detailed in my previous book "Custom Keyboard Introduction: How to Make Scattered Keyboards", there are keyboards in the world that implement such functionality through several methods. My research revealed that while there are some keyboards where the thumb section is completely independent as a module and can be replaced, there were very few that allowed free changes to the number and position of other keys.

Target Goal

People who dive into the custom keyboard world probably have their ideal keyboard in mind and work daily on their creations. This could be called the project goal. In my case, "a keyboard that can be customized freely" immediately came to mind. Looking at the words alone, it might seem like a general-purpose product aimed at a wide audience from the start, but it came to mind as something I wanted to use myself.

Looking back at my history, I noticed that what I wanted from keyboards changed over time. When I was trying various logical layouts, there were various patterns where I needed more keys or conversely where they were in the way. Right now is when I want to try column stagger, but I think times will come when I want to explore possibilities of other layouts.

Looking at shorter periods, it also differs by work content. The optimal keyboard differs in shape between writing programs and playing Factorio. This is particularly evident with what are commonly known as one-handed devices. Sometimes having a trackball is convenient, while other times I want to add more keys in that location.

The applications I frequently use, desk environment - everything changes over time. Impermanence of all things.

In this context, I thought flexibility that isn't bound to one fixed form is important. I decided to aim for a keyboard where I could freely arrange necessary functions when needed. Furthermore, I thought it was important that such customization could be done dynamically and easily. Without being able to make changes while actually using it, adjusting itself becomes burdensome.

Based on these thoughts, I established the concept as a "flexible and dynamic" keyboard. Based on this concept, I've been working on development daily from the beginning to the present.

Architecture Foundation and Technical Elements

From here, I'll get into the development content.

Keyboard as a System

Looking at keyboards anew, I can see that data input by users is sent to the PC via multiple components.

When a user presses a key, first the key switch moves (if mechanical) and conducts -> components connected to the switch like hot-swap sockets -> board traces -> MCU pins -> and then it's generally read and processed by firmware. Each part functions as a component specialized in its own processing, and by cooperating with each other via defined interfaces, they construct one keyboard system. If this interface is maintained, it's possible to insert another component in between and change the processing. In hardware, this is often defined as standards. Components other than keys that are common in custom keyboards, such as trackballs, rotary encoders, and displays, can be understood in the same way. In software architecture terms, Service-Oriented Architecture (SOA) would be close.

Usually, due to hardware design and cost considerations, this is often handled as a monolithic system. However, I thought that if these were physically separated, it would be possible to freely add parts or adjust positions. In other words, I aimed for a system where various interfaces are designed as independent modules that can be freely combined and used. Since I rarely saw keyboards over 60% where the keys themselves were modularized, I arbitrarily named this the "full modular method"^[3].

Encounter with modulo and I2C

Based on this concept, when I researched information, I came across modulo proposed by biacco-san several years ago. Unfortunately, development doesn't seem to be active recently, but the book described a design where the brain part called "pendant" and other modules are connected via I2C, which seemed directly applicable.

Since I was an electronics novice, I first learned about the I2C communication method here and was impressed by its convenience. For those familiar with circuit design, this might be common knowledge, but until then I thought "wouldn't you need as many pins as there are devices?" and was about to hit a dead end early in the design. However, with I2C, you can flexibly connect multiple devices by simply extending just two data lines and sharing them among each device. Moreover, it supports hot-plugging and allows devices to be handled with the ease of USB connections. It was exactly the connection method I was looking for.

So in early 2024, I was constantly conducting I2C operation verification. At that time, I was using Pro Micro and conducting various verifications. When I confirmed that multiple key modules could be connected without problems, I remember feeling relieved.

https://www.esplo.net/en/posts/2024/04/i2c_1_use_promicro

Advantages and Disadvantages of Full Modular Method

The greatest advantage of the full modular method is the high degree of freedom in number and arrangement, and dynamic changes. While typical keyboards cannot be changed from the physical layout determined by the manufacturer, the full modular method allows users to explore the optimal form according to their hand size and usage environment. I've become completely accustomed to column stagger, but I often hear voices around me wanting to use row stagger. Grid layouts and Alice layouts (not currently supported) are also popular. I often hear needs for fine adjustments like "I want to place just the middle finger column slightly higher." I think it would be great if such arrangements could be freely changed and optimal forms could be explored while keeping costs down.

On the other hand, there are also significant disadvantages to making modules independent. Connection complexity and cost increases become very big problems^[4]. Furthermore, parts where existing knowledge cannot be utilized inevitably increase, and verification and development time definitely increases. Also, since components connecting parts fundamentally increase, manufacturing costs clearly increase as well. In reality, most of Cue2Keys' development period was due to technical verification. I was barely able to get it to work properly, and there was a sense of running out of time.

Since it was so difficult, I absolutely cannot recommend this approach as a first custom keyboard. When considering sales, there's even more to do and it becomes harder. However, from a learning perspective, I found it very useful. Hardware requires circuit design from scratch, and typical firmware (QMK and ZMK) doesn't work as-is, so modifications are necessary. Furthermore, cases need to be designed from scratch^[5]. Beyond functional aspects, there were also challenges like physical fixing methods between modules and ensuring overall stability. I plan to introduce these in detail in the module development section of the second part.

Note that in this mechanism, if interfaces are matched, there's the advantage of easily connecting compatible products for expansion. Therefore, if the number of developers increases, not only users but also developers would benefit from increased knowledge - a scalable mechanism. However, the current situation is quite difficult.

Current Architecture

In the current Cue2Keys, key modules and knobs are connected to the pendant via I2C. The hub doesn't have an IC and is just an I2C relay point with various connectors. By preparing connectors as shown in the diagram, they can be recognized as I2C devices. Note that the mouse sensor uses 3-wire SPI, so it's separately connected directly to the pendant (details in the second part).

I2C Connector Pin Layout

Since I2C is a short-distance communication standard, countermeasures against attenuation are not specified. Since the speed is slow (400kbit/s mode), there's no need to worry too much, but it's somewhat affected by wiring length and cables. In verification, I conducted stress tests connecting modules to the limit and using extension cables. As a result, by placing strong pull-up resistors, it works without particular problems in normal use, matching well with I2C specifications. Since it's wired connection, not having to worry about power saving also contributes to a simple architecture. Currently, due to IC and connector constraints, the upper limit is 160 keys, but the design allows for more.

https://x.com/esplo77/status/1899728892820398094

Case Design Philosophy

With the full modular system mounted on a base, appropriate cases need to be created for each module. I had a vague sense it would be difficult, but it was actually very difficult and could be called a bottleneck in development. I'll leave the details to the second part, so here I'll record the overall design philosophy.

In Cue2Keys, I tried to avoid screw fastening as much as possible and work hard with 3D printer design. There are several reasons for this.

First, to avoid increasing parts like screws and nuts and making assembly complex. While it's just tightening screws, it becomes difficult with hundreds of them, and screws might come loose at some point.

Second, is the cost issue. Do you know the price of screws? I had no idea until now and thought they'd be about 0.1 yen each since they're everywhere, but I was shocked to learn that common stainless steel screws cost over 5 yen each. Of course, bulk purchases would likely get discounts, but at a few hundred pieces, they're quite expensive.

Third, I could make various shapes with the 3D printer. I originally didn't think I could fix things without screws, but with trial and error, it surprisingly worked out, and I felt the potential of 3D printers. Instead of screws, key modules use key switches for fixing, and other modules separate the base and lid and fix with clips. Balancing clip durability with sufficient fixing is difficult and still under adjustment, but it's an interesting area with various possible innovations.

The trackball module required screws and washers due to bearing fixing, but other modules work hard with clips. Each became different clip shapes, so those interested might find it interesting to look at the cases they have.

Cases are basically made with Bambu Lab A1 mini, and when resin printing precision is needed, I used JLC3DP. 3D printers have become essential tools I can't do without, and I want to continue using 3D printers to make various cases.

Design Concept

I think keyboard bodies generally have stylish and cool design directions as gadgets connected to PCs. On the other hand, since Cue2Keys has a mechanism like combining blocks, I was thinking of names and design concepts that align with that. While incorporating toy-like fun, each module is small and rounded, so I ended up with the current loose and cute direction.

Module characters are also made to match this. The main character Yui-chi was born quite early and has been useful for business cards and various announcements since it's easy to use. I've only drawn input modules, so I'd eventually like to complete all modules. Each takes about an hour to draw, so it's a matter of priorities.

For the website, I made a rough mock early in development, thinking I'd somehow manage it by the time of sales, and this situation continued for a while. Then I was caught up in function verification, couldn't take time for design, and it became last-minute, leading to chaos. For what happened next, please check the previous article.

https://www.esplo.net/en/posts/2025/04/keyket2025

Currently, I haven't been able to incorporate much concept into the product itself. I wanted to unify colors and appearance, and add small gags to board silkscreens, but there was absolutely no time. If I think I'll work on it after functions stabilize, it never gets done, so I now think it's important to organize task dependencies and proceed in parallel.

Sales Related

Managing Module Production Numbers

What happens when the number of module types increases? Managing quantities becomes difficult. For example, the Starter Set DX consists of key, hub, pendant, knob, and trackball modules, but you can't make it without stock of all modules. On the other hand, if you maximize sets, you can't provide individual modules.

Despite devising things like considering production numbers for each module at the manufacturing stage and breaking up sets at appropriate times to allocate to individual module sales, the struggle was in vain and there's a huge bias in module stock numbers. I half-accept this as an eternal challenge of modular products, but going forward I'm considering combining with made-to-order production or incorporating innovations to speed up module manufacturing cycles.

Online and Offline Sales

After the first sale at Keyket 2025, I'm currently conducting online sales on Booth. Booth is a convenient service with all basic functions including anonymous shipping, easy to use and low fees (though they just went up). While there are unsatisfying details, looking at other online sales services, I don't see perfect ones, and it's helpful that it's easy to use.

Also, I'm asking the familiar Yushakobo for consignment sales. Not only online sales, but stores where products can actually be displayed are extremely valuable, and from the seller's perspective, I'm truly grateful. Since there's no display without stock, it depends on timing, but if timing matches, I'd be happy if you could try it at the store.

Packaging Related

In Cue2Keys sets, I emphasize working out of the box. Meaning it works when taken out of the box and connected to a PC. Honestly, assembly and packaging are very difficult, but considering that module connections are numerous and it's difficult to get to the correct state, and that customization is difficult without starting from a properly working state, I've adopted this format.

Looking at the box, currently as a result of trial and error, I'm using B6 size cardboard that barely fits the DX set. I wanted to make a decorative box with a logo, but this was more difficult than imagined.

I need to determine the size, but since the modules themselves are under development and changing, and the product's external dimensions change depending on which modules are combined, the timing to place orders never came. Furthermore, cost is also a big issue. Since cardboard arrives as a matter of course when using major EC sites, I didn't realize it, but I learned that cardboard is more expensive than I thought. I thought it would be about single-digit yen, but even the small-sized cardboard mentioned above costs over 80 yen per piece. Custom printing and sized decorative boxes cost several times more, require minimum lots of 100 or more pieces, and inevitably have to be passed on to product prices. Therefore, I'll likely respond with simple packaging for the time being.

Since I couldn't make decorative boxes, I created masking tape. This was made as a trial for packaging use, and is a larger 5cm size than typical ones. When stuck as an accent on cardboard, you can enjoy a slightly fun feeling.

https://x.com/cue2keys/status/1914927365702254755

Summary

I've recorded the history (Part 1) of Cue2Keys from development start to just after initial sales.
Part 2 will introduce the specific evolution and technical details of each module.

https://www.esplo.net/en/posts/2025/08/cue2keys_history_2

脚注

1. Utilizing thumbs is also common in Beatmania IIDX, but I hadn't connected this to keyboards ↩︎

2. I put masking tape on them to reduce the brightness ↩︎

3. This is a term I only hear in PC power supply units ↩︎

4. In system development, this is frequently heard in microservice architecture ↩︎

5. The aforementioned book also makes scattered keyboards following this ↩︎