How I AI: Maddie Reese on Building a Pager, Printer, and Personal API with AI

Maddie Reese built a receipt printer that lets strangers anywhere in the world send physical notes directly to her desk, wired a real 1990s pager to modern Twitter notifications, and published an API for things like her coffee order and favorite restaurants. None of the projects are especially practical. That is part of the point. See How to Get Twitter/X Notifications on a Retro 90s Pager.

Maddie approaches hardware the same way many people now approach AI coding: start with a weird idea, dump the goal into Cursor, let the model ask questions, buy the parts, and keep connecting systems until the thing works. A year ago she still thought coding belonged to other people. Her dad showed her Lovable, she spent days building, and the jump from software into hardware suddenly felt reachable too.

In this episode of How I AI, Maddie walks through the systems behind all three builds, including the Raspberry Pi setup behind the printer, the absurd notification chain required to reach a legacy pager network, and why she thinks personal APIs could become a useful interface for AI agents and relationships.

Turning a thermal receipt printer into a real-world inbox

The project is simple enough to explain in one sentence: visit maddiedreese.com/message, type a note, and a tiny thermal receipt printer on Maddie's desk prints it almost instantly. During the recording, my test message showed up within seconds complete with the satisfying little receipt tear.

Start with the outcome, not the architecture

Maddie did not begin with hardware diagrams or a detailed technical spec. She opened Cursor and described the result she wanted in plain language. Her prompt focused on the experience, not the implementation:

I want to create a printer where anyone in the world can send me a message from a website, how best would I implement this? Let's brainstorm.

From there, she uses Cursor almost like a collaborator in a discovery session. Instead of asking for code immediately, she has the model interview her, clarify constraints, and narrow the design. She prefers Cursor's minimal agent view during this stage because it keeps her focused on the concept instead of scattering her attention across terminals, files, and browser tabs.

That back-and-forth eventually turns into a rough system design, a hardware shopping list, and a clearer understanding of where software ends and the physical setup begins.

Use AI for the shopping list, then verify everything

Once the workflow was clear, Cursor helped generate the parts list. The core setup uses a Raspberry Pi connected over Bluetooth to a mini thermal receipt printer small enough to fit in one hand.

Maddie is enthusiastic about using AI for hardware planning, but she is careful about purchases. She repeatedly asks the model to double-check compatibility before ordering anything because small mistakes become expensive fast. Most of the errors she catches are around cables, adapters, or assumptions about what devices can actually connect to each other.

Her rule is simple: trust, but verify. AI is good at narrowing the search space. It is still unreliable enough that she manually checks the recommendations before spending money.

Connect the website to the printer

The final system is surprisingly lightweight. It has three main pieces:

1. A public form at maddiedreese.com/message collects the sender's name and message.
2. Submitting the form logs the message in Convex and sends it to a service running on the Raspberry Pi.
3. The Raspberry Pi forwards the message to the thermal printer over Bluetooth.

One detail I appreciated during the demo: Maddie stores every incoming message in Convex even if the printer itself fails. That decision ended up mattering because her original printer eventually died after running continuously for months.

What changed once people could print to her desk

The project became more social than Maddie expected. People send notes from all over the world, including mountains, boats, and ships in the middle of the ocean. Part of the appeal is the physicality. Internet messages usually disappear into tabs, feeds, or notifications. These arrive as objects.

The printer also changed how she thinks about hardware projects in general. Instead of treating physical computing as something reserved for electrical engineers, she treats it as another interface layer AI can help her navigate. She does not need to understand every line of generated code to get a meaningful result. Her goal is to understand enough to troubleshoot, iterate, and keep the system running. You can follow the full implementation in How to Build a Physical Inbox with a Raspberry Pi and AI-Generated Code. See How to Build a Physical Inbox with a Raspberry Pi and AI-Generated Code.

Routing Twitter notifications through a real pager

The second project started with a very specific goal: make an actual retro pager buzz whenever Maddie gets activity on Twitter. The fun of the build comes from forcing modern APIs to cooperate with outdated infrastructure that was never designed for today's internet.

Find a pager that still works

One of the stranger discoveries in this episode is that pager networks still exist. Maddie found Spok, a remaining large paging network, then bought a compatible device through an authorized reseller that normally serves hospitals and medical staff.

The setup process itself felt frozen in time. The reseller's website looked decades old, but the pager arrived activated with both a phone number and an email address that could receive messages.

Bridge modern APIs into legacy infrastructure

Getting Twitter notifications onto the pager required multiple layers of translation because the pager network has strict limitations around incoming email domains. Maddie ended up building a relay chain across several services:

1. An interaction with her Twitter account generates an API event.
2. A Cloudflare Worker receives and processes the event.
3. The worker formats the notification and sends it through Resend.
4. Because the pager network rejects newer custom-domain emails, Resend delivers the message to Gmail first.
5. Gmail forwards the message to the pager's older network email address.
6. The pager finally displays the forwarded message.

The resulting workflow is hilariously overengineered compared to a normal push notification system, but that is exactly why it works as a project. Maddie is not optimizing for elegance. She is optimizing for delight.

That mindset came up repeatedly in this episode of How I AI. AI-generated code lowers the cost of experimentation enough that weird routing chains and unnecessary integrations become viable creative projects instead of week-long engineering exercises.

Publishing a personal API

Maddie's third project is less about hardware and more about treating personal preferences like structured data. Her API stores the kinds of details friends usually have to text for repeatedly, including coffee orders, favorite snacks, pets, restaurants, and scheduling information.

The motivation was surprisingly practical. She liked the idea of making it easier for people to do thoughtful things without spoiling the surprise by asking a dozen logistical questions first. Instead of texting someone for their order or favorite restaurant, an authorized person or agent could simply query the API.

The surprisingly human data model

The API includes a mix of useful logistics and deeply specific personal preferences:

• Coffee order.
• Her pets: Mabel, Lola, and Moon.
• Favorite snacks, including simply salted popcorn with nutritional yeast.
• Time zone.
• Favorite San Francisco restaurants, including One's Rocket Sushi and Abel's Front Room.

Why agents may care more than humans

During the conversation, we ended up talking less about humans manually querying APIs and more about what agents could eventually do with this kind of structured personal context.

A future workflow might look something like this: an agent checks Maddie's API, sees when she will next be in San Francisco, picks one of her preferred restaurants, and prepares a reservation without requiring another round of messages. We also talked about extending the API with POST endpoints so agents could send messages directly to her printer or pager instead of only reading data from the system.

What makes the idea interesting is not the technical complexity. The API itself is fairly simple. The interesting part is the framing. Maddie treats personal preferences as reusable infrastructure that software can interact with on behalf of relationships.

Build for delight, not efficiency

The strongest throughline across all three projects is that Maddie is not waiting for permission to work with hardware. She uses AI tools to close the confidence gap, then learns enough along the way to debug problems, evaluate suggestions, and keep iterating.

She compared her understanding of code to partially understanding a second language. She cannot always speak it fluently from scratch, but she can increasingly read it, recognize patterns, and tell when something sounds wrong. That is enough to build systems that connect APIs, databases, Bluetooth devices, printers, and old paging networks.

The workflow worth copying here is not the pager or even the printer itself. It is the process: describe the outcome in plain language, let the AI ask clarifying questions, buy the minimum viable hardware, and keep stitching systems together until the physical experience matches the idea in your head.

Where this works especially well is in playful personal projects where speed and experimentation matter more than pristine architecture. Human judgment still matters around hardware compatibility, debugging, reliability, and deciding which ideas are actually enjoyable enough to keep around after the novelty fades. Maddie's projects succeed because they are intentionally a little impractical. The fun is the feature.