DigitalMonk designed and built a compact, battery-powered audio device that plays a Bible verse at the press of a button — hardware, firmware, and companion app, end to end. The product, sold as the Bible Button, holds a full year of King James Version scripture: one press delivers a spoken verse through the built-in speaker, no screen and no setup required from the person using it. Behind that deliberately simple interaction sits a custom ESP32 board, an internal audio store, and a mobile app that lets the owner manage what the device says and how it says it.



The device was commissioned by a US-based pastor with a vision for accessible scripture — a way to put daily verses in the hands of people who don't want an app, a subscription, or a screen to navigate. Older congregants, children, and anyone who simply prefers a physical object over a phone were all part of the audience. That shaped the whole engineering brief around one constraint: the person holding the device should never have to think about the technology.
In practice that meant a few hard requirements. The primary interaction had to be a single, obvious press that plays a verse. The audio had to be loud and clear enough to be understood across a room, from a small enclosure, without a wall adapter. The content — 365 verses of KJV audio — had to live on the device itself, so it worked anywhere, with no streaming and no network dependency during normal use. And because the owner still needed a way to load and update that content, there had to be a path to manage it that didn't involve cables, drivers, or technical skill. Those tensions — dead-simple for the end user, fully manageable for the owner, self-contained on cheap hardware — are the real story of the build.
DigitalMonk delivered the complete stack: custom PCB and the embedded firmware that runs it, a React Native companion app, and the WiFi provisioning layer that connects the two. The device is built around an ESP32-WROOM-32E module, drives a small speaker through a MAX 9-series class-D amplifier, stores its verse audio on internal flash, and is powered from a battery with a physical power switch. The companion app handles everything the owner needs — loading content and managing the device — over a local WiFi connection the device creates itself. The sections below walk through each layer and the choices behind it.
The board is a custom design cut to a non-rectangular outline so it drops cleanly into the round enclosure — the reason the PCB in the photos looks like an interrupted disc rather than a tidy rectangle. Packaging drove the layout as much as the schematic did: the speaker, the top-facing press button, the power switch, and the battery leads all had to land where the enclosure expected them.
At the center is the ESP32-WROOM-32E module (U6). It handles everything — button input, audio playback, WiFi, and the small web server the app talks to — which kept the bill of materials lean by avoiding a separate microcontroller and radio. Audio output runs through a MAX 9-series class-D amplifier, chosen because class-D is efficient enough to run hard off a battery without draining it and drives the small speaker to a genuinely audible level from a sealed enclosure. The amplifier takes a digital audio stream from the ESP32 over I2S, so the signal stays clean right up to the speaker terminals rather than picking up noise across an analog path.
Verse audio is stored on the module's internal flash memory — a deliberate call to avoid an SD card slot. An SD card is one more mechanical part, one more failure point, and one more thing a user could remove or damage; keeping the content in flash makes the device more robust and cheaper to build, at the cost of a tighter storage budget that the firmware and audio format had to respect. Physical controls are kept minimal and obvious: a large primary button to play a verse, dedicated volume-up and volume-down buttons, and an SW1 slide switch to cut power completely. Test points and a programming/debug header were left on the board for bring-up and production flashing.

The firmware's job is to make a battery-powered radio-and-audio device feel like a toy. On power-up it initializes the audio pipeline and waits. A press on the main button selects a KJV verse and streams it from flash to the amplifier over I2S; the volume buttons adjust output on the fly and the device remembers the setting. Everything the end user touches resolves to those few actions, with debouncing on the buttons so a firm press never triggers twice.
Because the audio lives in flash rather than on a card, the firmware manages that space carefully — indexing the verse files, decoding the compressed audio on playback, and keeping the working memory footprint small enough to leave headroom for the WiFi stack when it's needed. The same firmware also hosts the provisioning and content-management path described below, which only wakes up when the owner explicitly puts the device into setup mode, so the radio isn't burning battery during ordinary day-to-day use.
The owner-facing side is a React Native companion mobile app, built cross-platform so a single codebase serves both iOS and Android. Its purpose is content management: connecting to the device and loading or updating the verse audio it plays. Keeping this in an app — rather than on the device — is what let the physical product stay screenless and single-purpose. The person receiving a Bible Button never has to see the app; the person who set it up uses it once to get content on, and again only when they want to change something.
This is the layer that ties a screenless device to a phone without asking the user to type anything on the device itself. The ESP32 runs in SoftAP mode — it broadcasts its own WiFi access point. The companion app connects the phone directly to that access point, and the device serves a small HTTP server over the local link. Content sync then happens as ordinary HTTP requests from the app to the device: the app pushes verse audio and settings straight to the device's flash over that private connection, with no cloud service, no account, and no internet dependency in the loop.
The design decision here is worth calling out: because provisioning is peer-to-peer between the phone and the device's own access point, the whole flow works out of the box, anywhere, even somewhere with no WiFi network at all. It also means no verse content ever passes through a third-party server — a sensible property for a faith product a customer owns outright.
Fitting an ESP32, an audio amplifier, controls, and battery power onto a custom board outline that had to nest inside a small round housing meant the layout was constrained before a single trace was routed.
Dropping the SD card made the device more reliable but capped how much audio it could hold.
A screenless device can't show a network list or a password field.
WiFi and an audio amplifier are both power-hungry.
DigitalMonk delivered the Bible Button as a complete, manufacturable product: a custom PCB, the ESP32 firmware that runs it, a cross-platform companion app, and the provisioning layer that connects them — engineered to be assembled, boxed, and shipped to end customers. The client took ownership of a device that does exactly one thing extremely well for the person holding it, while remaining fully manageable for the person who owns it.
The build is a clean example of what the ESP32 engineering team behind this project does across contexts: the same rigor that goes into an audio device applies whether the application is scripture, retail, or industrial. It's also a companion piece to an offline ESP32 Bible verse display we built — a related faith-tech device that solves for daily inspiration on a screen rather than through audio, with a very different hardware and firmware approach.



Whether you need a custom PCB, embedded firmware, or a companion mobile app, DigitalMonk can help turn your idea into a production-ready product.