build log #1
product brief, development roadmap
focus
This newsletter is about the journey of bringing to life a physical product from scratch, from concept all the way to manufacturing.
The product we’ll be building along the way is a device that allows you to take your existing, old electronics and instantly turn them into your own little cloud.
Think about all the smartphones, tablets, laptops, and maybe even desktops that are sitting in your junk drawer and simply collecting dust. What if you could connect these devices you already own into a cluster of tiny computers that can host all kinds of platforms for you? What if you didn’t have to be a sysadmin professional to do it, and instead you had a plug-and-play experience? Maybe you could get these to handle cloud storage, music streaming, or even language models, all without relying on subscriptions to Big Tech. That’s the pitch, that’s what we’re building.
background
If you’ve got a bunch of old devices stuffed in a drawer somewhere, you’re not alone. Surveys estimate that around four out of five US residents hoard unused smartphones. For tablets, the figure is around two out of three. Similar for laptops. That’s a lot of devices.
Even when electronics are recycled at authorized e-waste processors, less than 2% actually get reused in the EU. Most of them are reduced to raw metals, even if the majority of devices are still functional.
You can also ask language models to deep research the total processing power of hoarded devices and e-waste, and compare that to Big Tech data centers. It turns out that the sum total of consumer junk and e-waste lands comfortably above the largest data center, and around the total amount of compute across flagship AI data centers. But it is much more scattered and diverse, and so difficult to coordinate.
Now, you might be skeptical that your smartphone can compare to a GPU. Let’s use a concrete example, take my Pixel 8 from a few years back and an Nvidia GTX 1070 I pulled from a desktop. Both of them can have around 8 GB of GPU-available memory. The Pixel’s GPU has around 30x more half-precision throughput, while at the same time drawing 30x less power. However, the Nvidia card has 5x higher bandwidth between its memory and the actual cores, and much better cooling. It’s fair to say they’re at least trading blows, and both can run tiny language models alright.
features
Let’s get back to the product we’ll be building. To recap, “little cloud” will be a device that can physically connect to a bunch of other devices with wildly different form factors and computational resources.
On a hardware level, this new device will be responsible for handling the power, network, control, and cooling of the tiny computers attached to it. It effectively needs to bundle together the roles of several traditional pieces of enterprise equipment: a power distribution unit, a network switch, a KVM switch, and a coolant distribution unit.
On a software level, it will be responsible for automatically “recruiting” the diverse worker devices into a unified cluster, across which it can then orchestrate workloads to ensure users gain access to the platforms they want. It effectively needs to handle the job of traditional on-premises tooling used to define and run bare metal fleets, such as Talos and Kubernetes.
We’ll partially rule out some features to preserve focus for an initial version. First, we’ll leave an expansion slot for an eventual long-distance radio module, such that people will be able to connect their tiny personal clusters into a “little network” without relying on their internet service providers. Second, we’ll avoid adding connectors specific to solar power, but we’ll make sure portable panels with USB-C outputs can still be used to help people partially power their little clouds without relying on the grid.
development
We want to build towards a collection of files that can then be sent directly to manufacturing houses. These standardized files taken together specify the entire product, from the enclosure through the printed circuit board to the firmware, and allow the product to be manufactured reproducibly across fabs. This is known as “digital fabrication,” and allows us to avoid having to rely on any one particular manufacturing business.
We’ll use Onshape for modeling the enclosure and KiCAD for the printed circuit board, mostly because they’re the only CAD tools I know for these respective jobs. Here’s a picture of an open frame rig for which I used Onshape to model the mounts for the computer parts, it was pretty okay to work with. We’ll use Rust for low-level software, as it seems to have a decent path to native hardware on mobile devices, and because it’s the only language I used to get language models to run on consumer devices. It was GPT-2 back then, simpler times.
The design files would be open. The litmus test for openness here is whether someone has all the files they need get their own device built directly with a turnkey manufacturer. However, economies of scale help drive down costs significantly at higher volumes, and so people should be able to participate in those savings. We’ll probably aim for a first real production run through a platform like Crowdsupply, which helps open hardware projects with crowdfunding and fulfillment logistics.
format
I’m pretty excited about building this in public, both for the accountability pressure and as a way to meet people who might be interested in this little device. I’ll try sharing weekly build logs in here, first time publishing on Substack. We might occasionally visit places like makerspaces, e-waste processors, manufacturing houses, or repair workshops to mix things up.
If you’d like to follow along the full journey of bringing a product to life, including different kinds of engineering that go into it, consider subscribing! If you’re curious about this actual product and want to steer its development, use the comments to share feedback and suggestions. Either way, looking forward to seeing you around!
