My son is getting to the age where he wants to talk to his friends. Not text. Not FaceTime with the front camera pointed at the ceiling. Actually talk, the way I did when I was a kid, picking up the phone in the kitchen and stretching the cord around the corner for some privacy.
The problem is that giving a kid a phone in 2026 means giving them a surveillance device with a subscription plan and an algorithmic feed. The phone app is the least-used thing on it. I wanted to give him something different: a real phone that makes real calls to a small list of trusted friends, with nothing else. No screen, no apps, no subscriptions, no spam. Just a phone that rings when someone calls and connects two people in a conversation that belongs to nobody but them.
So I built one.
The idea
Kids today are growing up without ever making a phone call. That sounds like a small thing until you think about what phone conversations actually develop: active listening, thinking on your feet, reading someone’s tone, sustaining attention on a single person. Text doesn’t build any of that. And the devices we hand kids as “phones” are really content consumption terminals that happen to have a dialer buried in a folder somewhere.
I think there’s real value in a device that does exactly one thing. A phone that rings with a mechanical bell instead of a push notification. A phone where the conversation evaporates when you hang up, no logs, no recordings, no screenshots. Not because there’s something to hide, but because kids deserve a space to be awkward and figure things out without a permanent record.
Digits is that device. End-to-end encrypted voice calls between vintage desk phones, over the internet, with a hardware kill switch that physically disconnects the microphone when the handset is on the cradle. One-time hardware cost, no subscription, open source.
Starting from scratch
I have about 30 years of software experience. Hardware experience? Basically zero, unless you count 3D printing enclosures and wiring up WLED strips. I had never designed a circuit, never read a datasheet for a purpose beyond curiosity, and definitely never laid out a PCB.
I started by buying a pair of Sangyn 2500 retro desk phones off Amazon. Cherry red, touch-tone keypad, mechanical bell inside. They look like the phone on your grandmother’s kitchen wall. Then I tore them apart.
The teardown was the fun part. I needed to figure out every wire: which pins on the keypad ribbon cable mapped to which rows and columns, what resistance the bell coil presented, how the hook switch mechanism worked, what the handset wiring looked like. Multimeter in one hand, notebook in the other, testing continuity on every connection until I had the full picture.
The original PCBs were useless for my purposes. They were designed for analog phone lines, not internet calling. So I gutted everything and started wiring from scratch on a perfboard: a Raspberry Pi Pico H for real-time hardware control, a Raspberry Pi Zero 2 W for the networking and audio stack, and a Codec Zero audio HAT for microphone input and earpiece output.
Wiring it all together on a protoboard taught me things I never expected to care about. Like the fact that ElectroCookie perfboards have connected copper strips on the underside, which will short your signals if you don’t plan your layout. Or that an unshielded cable run longer than a few inches acts as an antenna for 60Hz EMI and fills your audio with hum. Or that a 100nF ceramic bypass cap at the right junction kills 97% of ultrasonic noise you didn’t even know was there.
The stack
Each Digits phone is two processors working together.
The Pico H runs C firmware and handles everything timing-sensitive: scanning the keypad matrix, reading the hook switch, driving the status LED, and controlling the ringer. The ringer circuit alone was an adventure. The original bell coil needs around 100V AC to ring properly, so I’m running 12V through an L298N H-bridge motor driver into a step-up transformer, alternating polarity at 20Hz. When that phone rings, it sounds exactly like a real phone from 1985. Because it is.
The Pi Zero 2 W runs digitsd, a Go daemon that handles the entire VoIP stack: WebSocket signaling, WebRTC media via the Pion library, Opus audio encoding and decoding, ALSA audio I/O, NAT traversal with STUN and TURN, OTA updates, Wi-Fi provisioning, and device pairing. The two processors talk over UART with a simple line-based ASCII protocol.
The signaling server is also Go, running in the cloud. It relays call setup messages between phones but never touches audio. SDP offers, answers, and ICE candidates flow through it. The actual voice data goes directly between the two phones, encrypted with DTLS-SRTP. Even if someone compromised the server, they couldn’t listen to calls.
On top of that there’s a web app (htmx + Tailwind) where parents manage their household, add phone lines, and exchange invite codes with other families to connect their networks. Once two households are linked, any phone in one household can call any phone in the other.
I also built a custom OS image pipeline that produces bootable SD cards with everything pre-configured, including a recovery partition for factory resets. The recovery system boots from its own partition and can safely overwrite the main OS without risk of bricking the device. Same architecture Android uses.
From soldering iron to PCB design
The protoboard builds work. I have two phones making encrypted calls to each other right now. But a perfboard covered in hookup wire and hot glue is not something I can hand to my son’s friend’s parents and say “here, plug this in.”
So I learned KiCad.
Going from zero electronics experience to designing a custom carrier PCB was one of the steepest learning curves I’ve hit in a long time, and I’ve been doing this professionally for three decades. Schematics, footprint libraries, design rules, trace widths for different current loads, ground planes, mounting holes that line up with the original phone’s screw posts. It’s a completely different discipline from software. There’s no undo button when you’ve already sent the board to fabrication.
The PCB integrates everything the protoboard did: power regulation (12V to 5V buck converter), Pico socket, Pi + Codec Zero headers, and connectors for the keypad, hook switch, bell ringer, handset audio, and status LED. One board, drop-in replacement for the rats nest of wires.
As of this week, the boards are back from fabrication and the components are sourced. If they validate, I can build a phone in an afternoon instead of a weekend.
AI as collaborator
I need to be honest about this part because it’s central to how this project happened at the pace it did.
I use LLM agents all day long at work for software engineering. That’s table stakes at this point. But when I started Digits, I had a genuine question: would AI collaboration actually work for learning and building in a domain I had no experience in? Software is one thing. Electronics, KiCad schematics, PCB layout, kernel module dependencies, analog circuits for driving a bell ringer through a step-up transformer? That felt like a stretch.
So I treated it as an experiment. Could I use an LLM as a coworker to validate what I’d designed, catch mistakes in my schematics, explain why a particular bypass capacitor matters, and push me toward better practices? Not just answer questions, but actually review my work the way a more experienced hardware engineer would?
It turns out the answer is yes, and it worked better than I expected. When I was laying out my first KiCad schematic, Claude caught that I was missing pull-up resistors on an I2C bus. When I was debugging audio noise, it walked me through the EMI implications of my cable routing. When I needed to understand the brcmfmac WiFi driver’s firmware loading sequence on a Pi Zero 2 W, it could read kernel dmesg output and reason about SDIO bus probing and module dependencies in real time. It’s not perfect. It gets things wrong regularly, and I have to verify everything against datasheets and actual measurements. But as a collaborator who can context-switch between reading kernel logs, debugging Go process management, and reasoning about ext4 journal behavior without needing ramp-up time, it’s genuinely useful.
I’ve been working with Claude (Anthropic’s AI) throughout Digits, and the acceleration has been significant. I make the architecture decisions. I decide what gets built, evaluate whether the suggestions make sense, and catch the things that are wrong. I read the logs, see what’s actually happening on the hardware, and direct where we dig next. Claude brings breadth and patience. It can hold the entire system in context simultaneously and iterate on fixes faster than I can type the problem description.
This project spans C firmware, Go systems programming, Linux kernel internals, audio processing, WebRTC, wireless networking, PCB design, and web development. No single person is an expert in all of those simultaneously. Having a collaborator who can be passably competent across all of them, while I bring deep judgment on the software side and learn the hardware side, compresses what would normally take a team several months into weeks.
This is not about replacing engineers. I have decades of experience and I’m making judgment calls constantly that the AI couldn’t make on its own. It’s about leverage, and about the surprising discovery that LLMs can be genuinely helpful for learning new disciplines, not just accelerating ones you already know.
Where it stands today
As of this writing, I have two fully functional prototype phones. They register with the signaling server, pair through the web app, and place encrypted calls to each other. The mechanical bells ring, the audio is clear, NAT traversal works, and the hardware kill switch physically disconnects the microphone when the handset is on the cradle. Everything I set out to build at the start of this project works.
That’s the part that still surprises me. Three weeks from “I wonder if I could do this” to two production-quality phones making encrypted calls over the internet. The core functionality is done. What I’m doing now is iteration: designing PCBs to replace the hand-wired protoboards, building a factory reset system that runs from its own partition, hardening the OS image pipeline. Making it something I can put in a kid’s room and forget about.
What’s next
Digits is open source under AGPL-3.0. The firmware, the daemon, the signaling server, the web app, the PCB designs, the OS image builder, all of it. If you want to build one yourself, the documentation is at digits.family and the code is on GitHub.
My immediate next step is assembling the manufactured PCBs and validating them. If that goes well, I’m building phones for my son’s friend group. The signaling server is self-hostable, so any family can run their own if they want complete control.
I’m not trying to start a business here. I’m building something I believe in because I think kids deserve better than what we’re giving them right now. A phone that rings, connects two people, and then goes quiet. No feed, no algorithm, no permanent record. Just a conversation that exists only in memory, the way it used to be.
If that sounds like something your family could use, go build one. I’ll help.