The Weekend I Built Hardware Again
How I went from a friend's idea to a working, 3D-printed electronics prototype with Claude at every step, and what that says about how fast physical products can be built now
June 2026
For the curious (start here)
A friend of mine cares a lot about one thing: there is almost nothing good for Arabic-speaking kids to listen to. Millions of children, a handful of decent podcasts, and a default that pushes them toward a screen and an algorithm. He wanted to build the opposite. Audio they can hold. No screen.
So I helped him build a physical version of the idea. A small box a child can use without reading, without a phone, without a parent setting anything up. You tap a printed card on the side, and the box plays a story out loud. Tap a different card, you get a different story. That is the whole interface. A knob for volume. A press to pause. Nothing to swipe.
The working prototype. Tap a card on the side, a story plays. The character on top is a beetroot, which is what "shamandar" means in Arabic.
The part worth telling is not the box. It is how it got made. I am not running a hardware company anymore. I spent the last couple of years deep in software. I built this in under twenty hours of actual work, spread across a few evenings and a weekend, mostly at my kitchen table, working alongside an AI the entire way. It mapped the design with me, helped me pick the parts, wrote the firmware, drew the 3D model for the case, and helped me find a print shop that turned that model into a physical object for under fifty dollars by the next day.
The same prototype, a decade ago, would have meant months of back and forth across a small team and easily several thousand dollars. This time it was under twenty hours and a couple hundred dollars in parts. That is the real story, and the rest of this post is the detailed version. If you only wanted the gist, you have it. If you want the build, keep going.
Where I'm coming from
For the last two years I have been building software. Alma, the company I run now, is an AI nutrition coach. It is an app, a backend, a pile of models and pipelines. No solder.
Before that, my whole career was hardware.
I trained as a mechatronics engineer. My graduate research was a robotic exoskeleton hand for stroke rehabilitation, the kind of project where you spend weeks getting a single sensor to read cleanly. Then I co-founded PUSH, a wearable that measured how athletes move. It ended up on more than 150 professional sports organizations and was acquired by WHOOP in 2021, where I stayed on as VP of Product. I have shipped real devices to real customers. I know what a bill of materials is. I know the specific feeling of a project stalling for two weeks because one component is out of stock.
That is the context for why this build surprised me. I remember how expensive every step of physical prototyping used to be. Not just in dollars. In time, in coordination, in the sheer number of people you needed in a room. Electrical, firmware, mechanical, industrial design. Each one a specialty, each one a handoff, each handoff a delay.
I went back into hardware for a weekend and the loop felt nothing like I remembered.
The idea
My friend's project is called Shamandar. The name means beetroot in Arabic, which is why the character that became the mascot is a small, round, slightly smug beetroot.
The product thesis is simple. There are millions of Arabic-speaking children and very little high-quality audio made for them. Most of what exists is formal, dry, or just a YouTube channel that needs a screen. Parents increasingly want screen-free options. The model that already works for English-speaking kids, the Toniebox and Yoto style of tap-a-card audio player, did not have a good Arabic equivalent. He is building the content. I offered to prove out the hardware.
The vision we were aiming at. A soft, friendly object with a character on top and physical story cards. This is a render, not the prototype. Holding the dream and the breadboard in the same hand is part of the job.
The core mechanic, which is the same one Yoto and Toniebox use, is worth understanding because it shapes every technical decision after it: the card holds almost nothing. There is no audio on the card. The card carries a tiny ID. The device reads that ID, asks the internet what it means, and streams the right story. Cards stay cheap and printable. The library lives in the cloud and can grow forever.
That is the spec in one sentence. Getting from that sentence to a box on a table was the work.
Step 1: Mapping the spec with Claude
I started where I now start most things. A long conversation.
I told Claude what the device needed to do and asked it to think with me about how to actually build it. Not code yet. Architecture. What reads the card. What plays the sound. What holds the power. What talks to the network. Where the tradeoffs are.
This is the same move I describe for software design: use the model to map the system before you commit to anything. The questions it is good at are the ones that bite you later. Does the card reader need to sit flush against a thin wall, or does it need focal distance like a camera would. If it streams audio, where does the audio decode, on a server or on the chip. How do you power it so it survives the current spike when WiFi turns on. What is the cheapest path that still feels reliable.
We landed on a clear shape. A single microcontroller with WiFi as the brain. An NFC reader for the cards, because NFC works through a thin plastic wall with no line of sight, which a QR camera could not. A small class-D amplifier and speaker for sound. A rotary encoder for volume and play and pause. A lithium battery that charges over USB-C. Audio streamed from a server, decoded on the chip.
By the end of that conversation I did not have a product. I had a parts strategy and a list of the specific risks that would decide whether it worked.
Step 2: Sketching the core pieces
Once the shape was clear, I had Claude get concrete about the pieces and how they connect. Which pin does what. What talks over I2C, what talks over I2S, what needs its own power rail. This is the unglamorous middle of hardware, the wiring map, and it is exactly where a model that has read every datasheet and every forum thread earns its place.
It is also where the first real-world gotcha showed up, on paper, before it cost me anything. The two pins I was about to use for the encoder were silkscreened on the board as audio DAC pins, which is the kind of labeling confusion that eats an afternoon. Naming it out loud ahead of time meant I wired it right the first time.
Step 3: Researching the parts
Then we went part by part and turned the architecture into actual products with actual part numbers.
This is a step I used to dread. It is hours of cross-referencing modules, checking voltages, reading reviews, confirming that two things will physically and electrically talk to each other, and confirming the thing is in stock somewhere that will ship to Canada. It is necessary and it is slow.
With the model it was a research conversation. We picked an Adafruit ESP32 Feather as the brain because it bundles WiFi and a lithium charger and a USB-C port on one board. A DFRobot NFC module for the card reading. A small I2S amplifier and a matched speaker. A rotary encoder. We checked each one against the others. We checked each one against my actual constraints, which were Canadian shipping and a desire to not wait three weeks.
Step 4: One cart, one vendor
Here is a small thing that matters more than it sounds. I wanted everything in one order, from one vendor, with one shipment.
When you buy hardware from five different stores, your project moves at the speed of the slowest, least reliable package. One delayed envelope from overseas and you lose a week. So I had Claude help me assemble a complete cart from a single distributor, DigiKey, and confirm every line was in stock before I bought anything.
The core electronics came to about 150 Canadian dollars.
| Part | Role | Approx. CAD |
|---|---|---|
| Adafruit ESP32 Feather V2 | Brain, WiFi, USB-C charging | 31 |
| DFRobot Gravity PN532 | NFC card reader | 44 |
| MAX98357A I2S amplifier | Drives the speaker | 9 |
| Mono enclosed speaker, 3W 4Ω | Sound out | 6 |
| Rotary encoder with push | Volume, play, pause, power | 7 |
| MicroSD breakout | Optional offline storage | 5 |
| Headers, jumpers, tactile buttons | Bench wiring | 17 |
The battery and the blank NFC cards came from local Canadian sources for another forty or so. One cart, free shipping over a hundred dollars, no part waiting on another part.
Step 5: Assembly and soldering
The parts arrived and the kitchen table became a bench.
Everything laid out and wired on the bench. Speaker, NFC reader, the Feather brain, encoder, battery, a protoboard, and a blank card. The tape measure shows up in a lot of these photos for a reason I will get to.
I wired the whole thing up loose first. Jumper wires, a protoboard for the power rails, nothing soldered permanently. The goal at this stage is not to be tidy. It is to find out whether the plan survives contact with reality.
The brain mid-wiring. This is the moment a plan turns into a knot of colored wire and you start to find out what you got wrong.
I soldered headers and the permanent connections once the layout proved out. Old muscle memory. The hands remember even when the calendar says it has been a few years.
Step 6: Batch testing, one component at a time
This is the discipline that separates a prototype that works from a prototype that sort of works and you never quite know why.
You do not wire everything together, power it on, and pray. You bring up one subsystem at a time and prove each one in isolation before you trust it. Claude wrote me three small, throwaway test programs, each one proving a single thing.
The first proved the audio path only. Turn the encoder, the pitch changes, sound comes out of the speaker. No card reader, no network. If that does not work, nothing downstream matters.
The speaker, isolated and proven before it joined the rest.
The second proved the card reader, offline. Tap a card, the device reads its ID and plays a simple tune stored on the chip. No WiFi involved. This confirms the NFC half works on its own.
The NFC reader, proven on its own. Tap a card, get an ID, with nothing else connected.
The third put them together with the network. Tap a card, fetch what it means from the server, stream the story over WiFi, decode it on the chip, play it. That third program is essentially the real product.
Each test passed before the next one started. When the full thing finally ran, there were no mysteries, because every piece had already earned its place.
Step 7: The firmware
Claude wrote the firmware. I reviewed it, ran it, broke it, and fed the breakage back.
The logic is not exotic. Boot, connect to WiFi, watch the card reader. When a card appears, read its ID, ask the server for the matching story, stream the audio, and decode it on the chip. The onboard light changes color to show state: waiting, fetching, playing, paused, error. The encoder sets volume and toggles play and pause. Holding it down puts the device into deep sleep so the battery lasts.
The interesting part of firmware is never the happy path. It is the dozen small, physical realities that no amount of clean code prevents. A few from this build:
- The amplifier popped loudly every time a stream started or stopped. That is a known behavior of this class of chip. The fix was to flush the audio buffer and pad silence around each clip in software.
- The card reader stopped detecting taps while audio was streaming. The scan window was too short. Widening it when the device was idle made it reliable.
- The audio library had a version trap. The newest release needed a newer chip toolchain than everything else wanted. We pinned it to the last version that built cleanly with the rest of the stack.
And one that was not a software bug at all, but is worth telling because it is the most hardware thing that happened.
A third-party battery arrived with its connector wired backwards relative to the board. Plugging it in put power on the wrong pins. A jumper wire flashed and acted as a fuse, the board's protection did its job, and nothing important died. The lesson is old and permanent: measure the battery against the board's markings before you ever plug it in. Software does not save you from polarity. This is the part of hardware that has not changed and will not change. Atoms bite back.
Step 8: End to end
With the firmware solid and every subsystem proven, I ran the whole loop the way a child would.
Tap a card. The light goes amber while it thinks. It fetches the right story from the server, the speaker comes alive, and an Arabic story plays. Turn the knob, the volume moves. Press it, it pauses. Tap a different card, a different story. It worked, on the bench, as a complete thing.
That is the milestone where a pile of parts becomes a device.
Step 9: Designing the enclosure in CAD
A working circuit on a table is not a product. It needs a body. This is normally where you hand off to a mechanical designer, or where a software person like me would get stuck.
I described the enclosure I wanted to Claude and had it generate the 3D model as code, in OpenSCAD, where the shape is defined by a script rather than drawn by hand. A base shell with pockets sized for each component. A lid. The card tap on the side wall, kept thin so the reader works through it. The volume knob at the back. And on top, the beetroot mascot.
Why the tape measure is in every photo. The CAD model is only as good as the real measurements you feed it. Every part got measured, and those numbers went straight into the design.
This is where I want to be honest about the boundary. The CAD was the messiest part. A model that fits real components has to match real measurements, and a render that looks right on screen can still be a millimeter off where it counts. I measured everything by hand, more than once, and the digital design only got trustworthy because the physical numbers were right. The model came out as a set of printable files: a base, a lid, the mascot.
Step 10: Rendering the concept
Before committing the working prototype to plastic, I had the model generate renders of where this could go. Not the functional box, but the polished product it points at.
A render of the eventual product. Soft, knit-faced, a power button, a card slot, a volume knob on top. This is the target, not the prototype.
The mascot on its own. Cheap to render, important to get right, because the character is most of what a kid actually bonds with.
These renders cost almost nothing to make and they do real work. They let my friend see the product, not the breadboard. They give the project something to rally around. And they make the gap between the dream and the current reality concrete, which is useful, because the next photo is the reality.
Step 11: Getting it printed
I had a 3D model. I needed a physical object. I do not own a printer good enough for a clean enclosure.
So I had Claude help me find a local 3D printing workshop, the kind of small shop that takes a file and hands you a part. I got quotes. The whole enclosure, base and lid and mascot, came in under fifty dollars. I sent the files, and it was ready to pick up the next day.
Sit with that for a second. From a description in a chat window to a physical, custom-made plastic object in my hands, over a single weekend, for the price of a couple of lunches.
Step 12: Assembly and the demo
I picked up the printed parts and assembled the real thing. Components into their pockets, lid on, mascot up top, knob on the back.
The whole interface, in one gesture. A child taps a card on the side. That is it.
Then I demoed it. Tap, story, knob, pause, tap, next story. The same loop that ran on the bench, now living inside something you can hold.
The finished prototype and its cards. Under twenty hours of work in total, mostly at a kitchen table.
It is not the render. The render is sleek and soft and says Shamandar on the side. This is a chunky cream box with a 3D-printed beetroot bolted to the top. But it is real, it works, and it proves the entire concept. The render is the promise. This box is the proof that the promise is buildable.
The backend
One piece sits off the device entirely. The stories do not live on the cards or, for now, on the box. They live on a small server I deployed to Vercel.
The device only ever talks to one address: my own. It sends a card's ID, the server looks up what that card means, and it returns the title and a link to the audio. The same pattern I use for everything else I ship. Describe the small service you need, deploy it on a push, and the device on the table can reach it minutes later. Adding a new story is adding a row, not reflashing hardware.
What still required me
In the spirit of being honest about where the AI stops, here is what I could not hand off.
The atoms. Soldering. Measuring. Plugging in a battery that turned out to be wired backwards. Picking up the print. Nobody and nothing did the physical work but me. Hardware still happens in the real world, and the real world still has polarity, tolerances, and current spikes.
The judgment calls. NFC over a camera. One vendor over five. Streaming over storing. Run off the battery directly instead of adding a boost board. The model laid out the options clearly and well. Choosing among them, with my own scar tissue informing the choice, was mine.
The taste. Whether the box felt right. Whether the mascot was charming or creepy. Whether the demo actually landed. A model can render a character. It cannot tell you the project lives or dies on whether a four-year-old smiles at it.
The relationship. This started because a friend cares about something. The reason it got built is human. The tools only changed how fast caring turned into a thing on a table.
The takeaway
I have built hardware the old way. Teams, handoffs, weeks lost to logistics, specialists for every layer of the stack. It produced great products and I would not trade the experience. But it was slow and it was expensive, and a lot of good ideas died before they ever became objects because the cost of finding out was too high.
This build was one person, at a kitchen table, in under twenty hours of actual work, for a couple hundred dollars in parts and under fifty in printing. The same prototype the old way would have taken months of back and forth across a small team and run into the thousands of dollars. I have lived that version. This was not that. The spec, the part selection, the firmware, the 3D model, even finding the print shop, all done in conversation with a model that was genuinely useful at every layer: electrical, firmware, mechanical, and industrial design. The layers that used to each need a person.
That does not make hardware easy. The atoms still bite. But the distance between "what if we built a thing" and "here is the thing, in your hand" has collapsed in physical products the same way it collapsed in software. I wrote a while ago that the value of software is shifting from encoding behavior toward describing it clearly enough that an agent can encode it for you. Standing over a 3D-printed beetroot that plays Arabic stories when you tap a card, I think the same thing is now happening to objects.
My friend has his proof. It plays stories. Kids can use it without reading a word. And it went from an idea to a thing you can hold faster than I would have believed, coming from the world I came from.
Rami Alhamad is the Co-Founder and CEO of Alma, an AI nutrition coach. He previously co-founded PUSH, a sports wearable acquired by WHOOP, and trained as a mechatronics engineer. He writes at Action Potential.