Our Origin

Lei Systems did not begin as a company with a vision statement. It began as a set of recurring frustrations, observed repeatedly from inside client organizations.

In 2016, the business that would later become Lei Systems was founded in Japan as Up&Up 株式会社, operated by Misako and Chris. At the time, we worked as individual consultants embedded in client teams, taking on contract roles across firmware development, hardware-related projects, cloud systems, and Agile process adoption.

We were close to the work. We wrote code, debugged systems, and delivered what we were hired to deliver. That proximity gave us a clear view into how products were actually built—and where they quietly bled time, money, and quality.

One engagement, in particular, changed how we understood our role.

​

The Transformational Project (Tokyo)

While consulting as a firmware developer for a Tokyo-based IoT client, Chris was assigned to develop firmware for an embedded IoT device the company had sourced from a Taiwanese systems integrator.

Internally, the device was a constant point of friction.

The most visible issue was cost. The unit cost was over $200, which made it nearly impossible for the client to bundle the hardware into the service they were selling. Even when sold to customers at cost, it was still too expensive to justify as part of the overall offering.

Less visible—but equally damaging—were field failures.

The device relied on a Linux-based system to manage communication with several external buses that required real-time behavior. In the field, the unit exhibited spurious and difficult-to-reproduce failures: missed timing windows, unreliable communication, and intermittent faults that were nearly impossible to diagnose conclusively.

From a systems perspective, the root cause was clear. Linux was being asked to do work it is not well-suited for: managing strict real-time protocols alongside higher-level application logic.

After reviewing the hardware and software stack, it became obvious that the system was both overpowered and misapplied.

Chris raised this with the buchō (department manager), explaining that the cost and reliability problems were related and solvable. The response was direct: this was not his concern. He had been hired as a firmware engineer, and in the Japanese corporate context, that defined the boundary of his responsibility.

Several attempts were made to raise the issue with others, but the result was always the same. The organization was structured such that the people experiencing the pain lacked the authority to challenge the architecture.

That changed when Misako started engaging with the project in a Product Management role.

​

Bridging the Authority Gap

As a product manager, Misako was included in discussions at the C-suite level and began framing the device not as a technical problem, but as a business liability—high cost, fragile reliability, and constrained adoption.

Over time, she convinced the shachō (CEO) to arrange a technical review involving Chris and the head of engineering.

In that meeting, Chris explained that the device’s expensive i.MX6DL application processor and its support chips were largely unnecessary. The cellular modem already in use—a Quectel EC21—contained its own Linux-capable processor and a supported SDK. With a different system architecture, the existing Linux-based application could be ported directly onto the modem.

More importantly, the redesign made it possible to separate concerns properly:

• High-level application logic would run on the modem

• All real-time I/O handling would be moved to a dedicated microcontroller

This would not only remove the need for the expensive SoC, but also eliminate the timing-related failures that had been plaguing the product in the field.

There was immediate interest—but also hesitation. They wanted a better and cheaper solution, but did not have the budget to hire a consulting firm to redesign the product.

We proposed an alternative: we would do the work at the same consulting rate already being paid, effectively redesigning the product from the inside.

​

Execution and Results

Within a week, a new hardware design was completed. Two weeks later, working prototypes arrived, including a first-pass enclosure produced using 3D printing so the team could evaluate the full device quickly.

On the software side, the existing system was fundamentally reworked. The original device relied on a mix of C, C++, and Python running across multiple components. As part of the redesign, the software was rewritten into a single, cohesive codebase using a new primary language. This made the system easier to understand, maintain, and extend.

Rather than adding more hardware, the new software was designed to run directly inside the cellular modem. Since the modem already contained its own computing environment, by adapting the software to run there, an entire class of unnecessary components could be removed from the design.

At the same time, the parts of the system that required precise timing—such as communication with external hardware—were moved onto a small, dedicated microcontroller. This allowed time-critical operations to run independently from the higher-level software, which eliminated many of the intermittent failures seen in the field.

Together, these changes resulted in a device that was simpler, cheaper, and significantly more reliable than the original design.

The redesigned product moved cleanly through EVP, DVT, and PVT with a Taiwanese manufacturer.

The final outcomes were unambiguous:

• Unit cost reduced to under $75

• Dramatically fewer QA and field issues

• A simpler, more manufacturable design

• A system better aligned with its actual functional requirements

The product was not only cheaper—it was materially better.

​

Business Impact Beyond the Device

Once the new unit cost was established, Misako was able to help the CEO reframe the business model.

With hardware costs now low and predictable, the client’s primary shareholders—a large Japanese bank—agreed to fund the devices upfront and offer them free of charge to customers.

The hardware cost could now be rolled into the service offering itself, reducing customer friction dramatically. Instead of asking clients to purchase an expensive device, the client could offer the service for approximately ¥1,000 per month (roughly $7).

This change led directly to a surge in adoption, particularly among smaller operators who had previously been unable or unwilling to absorb the upfront hardware cost.

What had been a constraint became a growth lever.

​

The Pattern We Couldn’t Ignore

This outcome was not the result of a single clever idea. It was the result of connecting decisions that were normally kept apart:

• Business model constraints

• Hardware architecture

• Software design

• Manufacturing realities

• Field reliability

What delayed this solution was not technical difficulty. It was organizational structure.

The people closest to the problems lacked authority.
The people with authority lacked technical visibility.

Once those gaps were bridged—even briefly—the solution became obvious.

We began seeing this same pattern across other clients: organizations paying for execution while suffering from early decisions that no one role was empowered to revisit.

​

Becoming a Different Kind of Consulting Firm

After several engagements like this, we made a deliberate decision.

Instead of operating as individual contributors buried in execution layers, we would work as a small, integrated team, engaging early and across boundaries—before cost, quality, and schedule failures became unavoidable. This approach proved especially effective for small and medium-sized companies building IoT products, where early technical and product decisions have outsized impact.

After returning to the United States, we reconstituted the business as Lei Systems LLC, carrying forward the same approach we had proven in Japan.

We exist to expose the decisions that matter early—while they are still cheap to change.