Building a Flexible, Future-Proof Compute System
- Mehrdad Majzoobi
- 26 minutes ago
- 6 min read
A hyper-modular hardware framework
There are two schools of thought in hardware.
The first is what companies like Juicero and Humane followed: raise hundreds of millions of dollars and tool up to ship hundreds of thousands of units, before anyone knows whether people actually want to buy them at that scale yet. It's a "go big or bust" pitch that sells well to investors and works occasionally — most consumer electronics ship this way — but the failure mode is brutal.
The second is to build in small batches, ship, get feedback, and ramp up gradually. This sounds obvious, but it's much harder in practice than in software. In hardware, your volume directly impacts your design — and design changes are expensive. Choosing this path means living with constant trade-offs; it's closer to an art than a textbook procedure. It looks a lot like the spiral model from software engineering.
Recent price fluctuations in RAM, CPUs, and storage have added another layer of risk on top of the usual supply chain volatility. Static component choices are increasingly fragile: there's no guarantee that the parts you design around today will be available or affordable six months from now.
In this article, I want to focus on computing devices in the hub / mini-PC form factor (small, always-on machines that sit on a desk or shelf), and how I've been trying to solve the small-to-mid-volume hardware problem with a hyper-modular, flexible system.
Customizable industrial design (ID) / chassis system
Computers come in all shapes and sizes. Remember the giant case you had on your desk years ago? That was a full ATX case. Too big for most people's taste today.
That's why the mini-ITX form factor gained popularity. But mini-ITX is also too large for many uses, especially anything in the smart hub / mini-PC range.
ITX has partially solved the form-factor standardization problem, but to make a standard work you have to shepherd the market into adopting it — and that's a hard problem on its own.
After doing some research and getting market feedback, I decided to build this framework around the Pico-ITX form factor. The X-Y profile is fixed (which is what makes it a usable standard), but height in the Z axis is adjustable — which gives us flexibility without breaking compatibility. A taller profile, for instance, can be used to build a NAS with 2.5" or 3.5" HDDs.
This serves as both chassis and industrial design baseline for arbitrary builds. At low volume, our off-the-shelf variant accommodates a 3D-printable back plane and has a fixed height. At larger volumes, the same extruded profile can be adjusted for enclosure height and port arrangement.
The top and bottom sections of the enclosure are also fully customizable, allowing for a display, LED ring, infrared RX/TX, audio, and more.
The following picture shows how the enclosure is adjusted to support the NVIDIA Jetson Orin Nano Super single-board computer.
Super carrier board (mothership)
Over the last few years, a handful of companies have been making NVIDIA Jetson carrier boards that support pin-compatible modules. Turing Pi is one of them; Waveshare in China is another.
Today there are several variants of carrier boards that are pin-compatible with NVIDIA modules (Jetson, Xavier NX, etc.) using the SO-DIMM 260-pin connector (similar to DRAM modules). These boards typically sell for around $80–$100.
A few variants include:
They generally have one or two M.2 NVMe slots, one M.2 E-key slot for WiFi/Bluetooth, one or two ethernet ports, a 40-pin header, and HDMI/DisplayPort outputs.
Intermediate adapter boards
To accommodate different design requirements for CPU, RAM, and other components, the carrier board has to work with a variety of compute module options. But Jetson carrier boards are designed for a fixed module form factor and pinout (SO-DIMM 260-pin).
To support other SOMs (system-on-modules), we can design adapter boards that sit between the SOM and the carrier board. The table below shows existing modules and adapters for various SOMs.
NVIDIA modules | |||
 |  |  |  |
Other compute modules
Radxa and Orange Pi both offer a wide range of Rockchip-based compute modules. As part of our long-term plan, we'll be designing SO-DIMM adapter boards for these modules.
Radxa modules:
Orange Pi modules:
What about Intel/AMD?
There is currently no Jetson-compatible SOM (or a clean adapter) for Intel x86 processors like the N95/N100/N150 used in the LattePanda Mu. The LattePanda Mu uses a different pinout than NVIDIA/Turing Pi modules, even though both share the SO-DIMM 260-pin connector. But an adapter, similar to the CM4/CM5 adapters above, could be designed.
Dimensions | |
 |  |
We could also design a new carrier board that's more friendly to LattePanda-style modules and more expandable than current Jetson-type boards.
COM Express Mini to SO-DIMM adapter
PCI-SIG, the organization behind the PCIe standard, also maintains a standard for computer-on-modules called COM Express. It's been used primarily in datacenter applications, mostly in the Basic and Compact form factors.
I've been collaborating with an ODM to develop a COM Express Mini module that supports different Intel chipsets. It's still under development and I can't share more specifics publicly yet.
 |  |
Alongside this module, we'll be designing a COM Express to SO-DIMM adapter so it can plug into existing NVIDIA-style carrier boards — and future carrier boards we design — that accept NVIDIA pin-compatible modules.
HMI and other modular peripherals
Devices often need a built-in HMI (human-machine interface) — a display, voice/audio interface — or M2M interfaces (machine-to-machine) like specialized radios (NFC, Zigbee, LoRa, and so on).
As part of this framework, I've developed a set of modular, interchangeable top HATs covering this functionality. Customers can also drop in Zigbee/Z-wave, LoRa, and other radios via an internal USB connector.
GUI + LED ring + audio (mics/speakers) + sensors | ||
 |  |  |
Other modules
Beyond compute modules, the framework brings together a unified set of sub-system modules to accelerate development of future systems, including:
Power modules (buck/boost, USB-PD, battery charging)
Sensors (radar/presence, camera, radios, etc.)
I/O modules (HDMI to USB-C alt-mode)
HDMI capture (for IP KVM, external screen recording, etc.)
What about software?
Most companies decide to be either a hardware company or a software company, not both. That was wise advice five years ago. It's not anymore. To compete today, you have to provide the full end-to-end experience — it's no longer enough to ship hardware and leave everything else for the customer to figure out.
As part of this modular framework, I'm developing an open source universal user interface that can run on any companion device:
iOS (iPhone / iPad)
watchOS (Apple Watch)
macOS
Android
Wear OS (Pixel Watch and others)
Web Browser
even TUI (Text UI)!
These apps will primarily be used by the end user for things like:
Basic onboarding and user registration
Access sharing
Filesystem management
Application management
Device settings
The mobile apps also expose hardware-specific features — NFC, camera, Bluetooth, and so on.
To keep this post focused, I won't dive deeper into the software side or how to build a universal UI here — that's a separate post (coming soon). In the meantime, you can browse the source for these applications on our GitHub: github.com/ubopod.
Be your own customer
I'm a big believer in "be your own customer," especially if you're building tools for other builders and makers. I used the same framework to build a product I now use every day to write embedded code: a personal AI coding assistant.
I decided to make a small batch and share it with other developers — we've now shipped over 100 units to early adopters on Kickstarter: Ubo Pod – Hackable Personal AI Assistant.
It's a constantly evolving product, and I use it daily as I develop new features for it. Some users have adopted the same workflow to build their own products (sensing and healthcare applications, mostly) using the integrated dev tools — Claude Code with custom skills, agents, and harnesses.
One of the device's biggest advantages: I can do embedded development remotely. My sensors, camera, audio peripherals, AI accelerators (Hailo / Coral), FPGA, and MCU all stay connected to my hub — I don't have to carry them around. I can drop into a tmux session, hand a task to the coding agent, walk away, and let it ping me when it's done.
Summary
This article introduces a hyper-modular build framework designed to accelerate product development and enable low-volume manufacturing while mitigating production and supply chain risks. The trade-off is real: a modular build typically increases COGS (cost of goods sold) compared to a design optimized for mass production. But mass production carries its own costs — significantly higher R&D and upfront tooling investment, plus full exposure to supply chain risk on every locked-in component choice.
The framework also imposes constraints of its own, particularly around form factor, the availability of compatible modules, and I/O limitations. It's not a free lunch — it's a different set of trade-offs, better suited to small and mid-volume builds where flexibility is worth more than per-unit cost optimization.
Need support?
If any of these challenges feel familiar and you're planning to build compute hardware — networking, NAS, sensing/monitoring, healthcare, anything in that space — at low-to-mid volume but aren't sure where to start, drop me a line at hello@getubo.com and I'd be happy to set up a time to chat.
You're also welcome to join our growing developer community on Discord: https://discord.gg/QSWH7tU8US