Church Verse Detection & Display System

I engineered a real-time bible transcription and display system that automatically detects Bible verses mentioned during live sermons and displays them instantly on sanctuary screens. Inspired by the high-pressure environment of church media teams, this project eliminates the delays and manual errors of traditional verse-searching, ensuring the congregation stays engaged with the message without distraction.

I chose a stack optimized for low-latency data processing and cross-device compatibility, ensuring the system remains stable during live broadcasts.

Real-time bible transcription and display
Layer

Technologies

purpose

User Interface

Next.js + Mantine UI

Provides a fast, SEO-friendly dashboard for media operators.

Backend Logic

Node.js & Express

Handles heavy lifting for real-time API routing and logic.

Database

PostgreSQL + Drizzle ORM

Relational storage for quick indexing of scripture and logs.

Audio Processing

Web Speech APIs

Captures and transcribes live audio directly from the browser.

Deployment

PWA (Progressive Web App) – Vercel frontend + Render backend

Ensures the system is installable and reliable across tablets and PCs.

The Problem: The Search Lag

Media teams have to listen, search, and display verses in a matter of seconds. This high-pressure scramble often leads to delayed visuals, wrong verses, and a distracted congregation.

The Solution: Automatic Queuing

I built a system that listens to the sermon and identifies Bible references as they are spoken. By using real-time voice tools and custom logic, the app automatically prepares the verse, so the media operator only has to tap a display button to show it.

The Impact: A Faster Booth

The system turns the media booth from a search center into a control center. It cuts out human error, removes the display delay, and keeps the congregation focused on the message rather than the tech.

Real-time bible transcription and display
Project Context

Solving a High-Pressure Workflow

I didn’t build this project based on a theory; I built it because I served on church media teams and saw the struggle firsthand. When a pastor mentions a verse unexpectedly, the media team has to scramble.

The Search Struggle

During a live sermon, a media operator is forced to perform a high-speed cognitive loop every time a verse is mentioned:

  • Listen carefully for the book and chapter.
  • Decide if the pastor actually wants that verse on the screen.
  • Search manually through a Bible app or database.
  • Format and send it to the big screens.

Even a 5-second delay feels like an eternity when the whole congregation is waiting. This high-pressure lag is exactly what I set out to fix.

The Problem: The Speed of Manual Search

In a live church service, every second counts. Currently, displaying Bible verses is a manual scramble that often fails for three reasons:

  • The Waiting Gap: Searching for a verse by hand takes too long. By the time it is found, the preacher has already moved on, leaving the congregation confused.
  • Too Many Tasks: Media teams are usually small and already busy managing sound, lights, and cameras. Adding a manual Bible search creates unnecessary stress and leads to mistakes.
  • Breaking the Flow: When a wrong verse appears or the screen stays blank, the focus shifts from the sermon to the technical glitch.

The Challenge: How can we get verses onto the screen instantly and accurately without adding more work for the media team?

Stakeholder Analysis:

Building for the Whole Room

A live service has moving parts. I designed this system to be a silent partner that supports everyone involved without getting in the way.

1

The Media Team

The Goal: Speed and simplicity.
The Solution: An interface that does the searching for them. Instead of typing, they just tap to approve a detected verse. This lets them stay focused on other tasks like sound and lighting.

2

The Preacher

The Goal: A natural sermon flow.
The Solution: The system is built to handle different speaking styles and accents. The preacher can speak naturally, knowing the tech will keep up without them having to slow down or change their delivery.

3

The Congregation

The Goal: Clarity and timing.
The Solution: Large, easy-to-read text that appears the moment a verse is mentioned. This removes the waiting gap and keeps everyone engaged with the message.

SUCCESS CRITERIA

To solve the real-world problems facing church media teams, the system had to hit these four marks:

1
Instant Results

The Goal: Verses must move from the preacher’s mouth to the screen in under 5 seconds.
The Reason: If it takes any longer, the preacher has already moved on and the congregation loses their place.

2
One-Tap Control

The Goal: Create a one-click system.
The Reason: Media teams are often small and busy. The app should do the heavy lifting (searching) so the operator only has to verify and tap.

3
Accurate Listening

The Goal: Correct detection across different voices, accents, and Bible versions.
The Reason: Every preacher speaks differently. The system must be smart enough to find the right verse regardless of how it is phrased or spoken.

4
Always-On Reliability

The Goal: A system that never crashes or freezes.
The Reason: Live services can’t stop for a technical glitch. I built in offline modes so the screens keep working even if the internet fails.

Ideation: The Big Questions

To turn these problems into features, I asked six “How Might We” questions. These helped me stay focused on building tools that actually work in a high-pressure church setting.

1

Speed & Accuracy

  • How might we detect and show a verse in under 5 seconds?
  • How might we make sure the app understands different ways of saying a verse (e.g., “John 3:16” vs. “The 16th verse of John 3”)?
2

Reliability

  • How might we create a manual backup that is just as fast as the voice detection if the room is too noisy?
  • How might we keep the app running perfectly even when the internet is slow or drops out?
3

Ease of Use

  • How might we give the operator total control over when the app is listening to avoid accidental displays?
  • How might we make the screen so simple that a volunteer with no training can use it with confidence?
Designing for Certainty

I used two methods to turn my questions into a working product: logic mapping and rapid sketching.

Logic Mapping: If…Then

I mapped out how the app should “think” during a service to handle unpredictable speech:

  • If the preacher says a verse, Then the app prepares it in a private queue for the operator
  • If the voice recognition is unsure, Then it shows a manual choice list to prevent mistakes.

Rapid Sketching: Crazy Eights

I sketched 8 different screen ideas in 8 minutes to find the fastest layout. This led to :-

  • The One-Tap Sidebar: A list of the last recently displayed verses, ready to live display again with one click lifting the need for the search flow again.
  • The “Listening” Pulse: A simple visual cue so the media operator knows the mic is active.

Key Insights from Ideation

  • Approval is Vital: The app should never show a verse automatically. A “Listen + Confirm” model is the only way to ensure 100% accuracy except for when a media member explicitly seearches the verse and hits enter since it has already passed the human confirmation.
  • Smart Choices: If a verse is mentioned that could mean two different things, the app shows both options for the operator to pick instantly.
  • Work Offline: Since church Wi-Fi can be unreliable/lag, I designed the app to store the Bible text on the device so it never stops working.

Design Directions: Engineering for the Sanctuary

I established six core directions to balance high-speed automation with the quiet, high-stakes environment of a live worship service.

1

The Human-in-the-Loop Detection

The Direction:

  • The system listens in short windows and shows detected verses on a private Candidate List area for the media team only to review and publish.
  • This ensures that if a preacher mentions a verse in passing, it doesn’t accidentally pop up on the big screen. Nothing goes public until a media operator confirms it.
2

Intentional Listen Control

The Direction:

  • A large, high-contrast “Listen” button acts as the main switch. When active, a subtle pulse (think Shazam) animation appears on the dashboard.
  • This gives the team total control over when the microphone is active, protecting privacy during prayers or announcements and saving system power.
3

Smart Verse Formatting

The Direction:

  • The machine learning transcription engine turns spoken words into a structured format: Book → Chapter → Verse which is then parsed to the backend lookup logic.
  • By combining computer speed with a quick human double-check, we guarantee 100% accuracy on the public screens.
4

Fast Manual Backups

The Direction:

  • The system includes two manual paths: a Search Bar for quick typing and display and a Step-by-Step Menu for navigating through books and chapters.
  • The Reason: If the room is too noisy for voice detection, the media operator has a Plan B that works in under 3 seconds, ensuring the service never has to pause for a technical glitch.
5

Offline-First Reliability

Final Direction:

  • I built the system as an installable PWA app that saves the entire Bible database and recent history directly onto the device.
  • Church buildings often have dead zones or spotty Wi-Fi. Storing the data locally ensures that even if the internet drops, the screens stay bright and the verses keep flowing.
6

High-Visibility Design

The Direction:

  • The interface uses large-format text and a dark-mode-first style to reduce the glow coming from enclosed media booths.
  • This makes the screen easy to read from several feet away and reduces eye strain for operators who are managing multiple displays in a dark room.

Information Architecture: The Split-View Strategy

In a live sanctuary, the operator needs data and control, while the congregation needs a clean, focused experience. I architected the system into two distinct interfaces that stay perfectly in sync.

The Media Control Interface (Operational Hub)

This is the operational interface used by the church media team during live services. Its design focuses on speed, minimal interaction, and clear system feedback. Contains the Live Control Dashboard which is the main screen for the media team and it includes :-

1

The Live Control Dashboard:

The heart of the app. It provides real-time “Pulse” feedback on the AI’s status (Idle, Listening, Searching, Ready). This transparency ensures the operator is never guessing if the system is working.

2

The Confirmation Layer:

To eliminate speech errors, I built a “Conflict Resolution” UI. If the preacher says “John 3,” and the system hears “1 John 3,” it presents both as options. The operator makes the final call with a single tap.

3

Muscle Memory Navigation:

The manual backup follows the natural hierarchy of the Bible (Book → Chapter → Verse). I optimized this layout so that volunteers of any skill level can find a verse in seconds without needing complex navigations.

The Church Display Interface (Public Output)

This is a view-only screen stripped of all buttons and menus. It ensures the congregation stays focused on the scripture.

1

Idle State

Displays a neutral background or church branding when no verse is active. This avoids unnecessary visual noise during the sermon.

2

Loading State

A subtle, non-distracting indicator that tells the congregation “content is coming.” This makes the transition feel smoother and more intentional.

3

Verse Display State

Built for the “back row.” I used high-contrast colors and font scaling to ensure the text is readable regardless of the projector quality or the room’s lighting.

How the System Works Behind the Scenes

To make the experience feel invisible during a live service, I designed four specific parts of the app to work together. This setup ensures that even if one part has a hiccup, the rest of the system stays reliable.

  • Speech Input Module
    Captures and processes spoken sermon audio.
  • Verse Parsing Module
    Extracts structured references (Book → Chapter → Verse) from speech.
  • Bible Data Store
    Provides cached verses for fast retrieval and offline reliability.
  • Display Sync Module
    Real-time model that pushes confirmed verses from the media dashboard to church screens instantly.

User Flows: Planning for the Unpredictable

A live sermon is dynamic, so the system must be flexible. I mapped out four key paths to ensure the media team always has a way forward, regardless of noise, accents, or internet issues.

1

The Happy Path: From Voice to Screen

This is the ideal scenario where automation does the heavy lifting while the human remains in control.

  • The Process: The team starts “Listening Mode” → The app detects a reference → A preview appears on the dashboard → The operator taps to confirm → The verse goes live.
  • The Goal: Minimize manual typing while keeping the media team as the final filter.
2

The Ambiguity Path: Handling Similar Verses

Sometimes, spoken words can mean two things. For example, “John 3:16” could be the Gospel of John or 1 John.

  • The Process: The app detects a reference → Multiple possible matches appear as cards → The operator selects the correct one → The verse is displayed.
  • The Goal: Maintain the speed of automation without ever sacrificing accuracy.
3

The Manual Fallback: Instant Backup

If the room is too loud or an accent is too thick for the AI, the service shouldn’t stop.

  • The Process: The operator notices a missed detection → They use the Global Search bar → They type the reference → The verse appears instantly.
  • The Goal: Guarantee that the service never slows down, even when automation isn’t the right tool for the moment.
4

The Offline Flow: Protecting the Service

Many sanctuaries have ‘thick walls’ and spotty Wi-Fi. I designed the system to be local-first.

  • The Process: The system detects a network drop → It automatically switches to the local database → Cached Bible text remains available → The operator continues manually without interruption.
  • The Goal: Ensure the congregation never sees a Connection Lost screen, maintaining a professional experience at all times.
KEY DESIGN DECISIONS

Designing for a live church environment meant prioritizing speed, clarity, and reliability over purely visual flair. I focused on decisions that would support media teams working under pressure, where there is no room for complex menus or guesswork.

Passive Listening Over Auto-Display

I decided the system should never send a verse to the big screen automatically. Instead, it listens silently and proposes the verse to the operator first.
The Reason: This keeps a human in control. It balances the machine speed with the oversight of the media team, ensuring that “passing comments” by the preacher don’t accidentally end up on the screen.

Total Interface Separation

The operator’s dashboard and the congregation’s display are two completely different views.
The Reason: This ensures that behind-the-scenes work, like searching, correcting, or system alerts, never distracts the audience. The congregation only sees a clean, finished result.

Manual Search as a First-Class Feature

In many apps, the manual backup is hidden away. I chose to make the search bar and navigation menu prominent and just as fast as the voice detection.
The Reason: Automation can fail in a loud room. By making the manual backup a first-class feature, I ensured the system remains dependable no matter what happens in the sanctuary.

Back-of-the-Room Typography

I chose high-contrast, large-scale typography specifically optimized for projection.
The Reason: Unlike a website designed for a phone, this text must be readable from 50 feet away in varying light. I prioritized clarity over visual clutter to make sure every seat in the house has a great view.

  • Real-time bible transcription and display
  • Real-time bible transcription and display
  • Real-time bible transcription and display
Full-Stack Engineering

Development & Implementation

After mapping out the flows, I built a system designed for speed and stability. The architecture focuses on three things: low delay, constant audio processing, and perfect synchronization between screens.

To achieve this, I implemented a full-stack architecture combining a modern React frontend with a real-time Node.js backend.

The Frontend: A Responsive Command Center

I used Next.js and Mantine UI to build a fast, clean interface that stays out of the operator’s way

  • Smart State Management: I used Zustand to handle real-time updates like the “Listening” status and verse previews without slowing down the app. This keeps the dashboard fast even when the system is processing a lot of audio data.
  • Simple Controls: Manual inputs are protected by quick validation logic. This ensures that if an operator has to type a verse manually, the system catches typos instantly so the wrong text never hits the big screen.

The Backend: Real-Time Communication

The backend, built with Node.js and Express, acts as the brain of the operation, coordinating the audio and the data.

  • Instant Sync: I used WebSockets(socket.io) to bridge the gap between the operator’s laptop and the church’s projector screens. When the Confirm button is tapped, the verse appears on the big screen instantly, no refreshing or waiting required.
  • Processing speech transcription results
  • Reliable Data: I chose PostgreSQL with Drizzle ORM to manage the Bible text. This setup allows for lightning-fast lookups, ensuring that once a verse is identified, the text is ready to go in milliseconds.

The Speech Pipeline: Listening with Precision

To turn spoken words into screen-ready verses, I integrated an offline-capable machine-learning speech model.

  • Continuous Detection: The system processes audio in small chunks, looking for patterns like Book → Chapter → Verse.
  • Offline Resilience: By using a speech model that runs locally, the system stays functional even if the church’s internet is unstable. This Local-First approach is a lifesaver in older church buildings with poor Wi-Fi.

Performance & Reliability

Because a live service can’t be rebooted, I built in several safeguards:

  • Lightweight Processing: The audio engine is decoupled from the UI, so the dashboard never freezes while the system is processing.
  • Dual-Path Design: Automation and manual controls live side-by-side, ensuring that the media team always has a way to get the Word on the screen.

How to Test the Live System

To experience the real-time transcription and multitenant display, follow these steps:

  • Create an Account: Register to set up your private church workspace.
  • The backend Wake-Up Period: Since this demo is hosted on a free-tier server, please allow up to 3 minutes after your first login or register attempt for the backend to “wake up” and become fully responsive.
  • Open the Display: Once your dashboard is active, click the View Display Screen link. This opens a dedicated window that uses a unique WebSocket connection for your specific church, ensuring total data privacy and zero cross-talk between churches.
  • Test the Audio: Ensure your microphone is enabled by giving the microphone access permission when prompted by the browser so the AI can “listen” and suggest verses to your dashboard.
  • Fully downloadable: The application is directly downloadable on your computer or tablet for faster access instead of having to open the browser every time. Use the “Install” button on your browser after successful account set up.

Note: The display screen will only initialize once a church workspace is successfully created and the socket connection is established. Once you’ve explored the features, please return to this page and click here to navigate to the feedback form below to share your experience and any suggested improvements.

Audio Input

Vosk Transcription

Verse Parser

Church Display Screen

WebSocket Broadcast

PostgreSQL Database

Beta Tester Feedback & Feature Requests

Great software isn’t built in a vacuum, it’s shaped by the people who use it. Whether you’ve noticed a small technical detail that could be improved, found a bug during the server wake-up phase, or have a big picture idea for a feature that would add massive value to your workflow, I want to hear it. This project is a living system, and your insights are the primary driver for its next set of updates.

1

Reflection: Designing for the Moment

Building this project taught me that designing for a live audience is entirely different from building a standard web app. In a sanctuary, there is no undo button once something is on the big screen.
The Balance of Power: I learned that while automation is powerful, human oversight is essential. The Confirmation step was the most important feature I built, as it gave the media team the confidence to trust the AI without fearing a public mistake.
Context is Key: This project pushed me to think about physical environments: lighting, distance, and high-pressure workflows, reminding me that great software must solve problems beyond the screen.

2

Project Impact

The system changes the media booth from a place of reaction to a place of preparedness. By automating the search process, the tool delivers three major wins:

  • Zero Delay: Verses appear exactly when they are needed, keeping the preacher and the congregation in sync.
  • Eliminated Errors: The confirmation layer ensures that the wrong verse never reaches the screen.
  • Team Confidence: Media teams can now focus on the “art” of the service like lighting and sound rather than the stress of a long Bible manual search.
3

The Road Ahead

The current version is a functional MVP (Minimum Viable Product) designed for real-world testing. My next steps focus on taking this from a successful test to a robust, scalable tool.
Short-Term: Validation
I am currently gathering feedback from church media teams to see how the system holds up during various service styles. Their insights on accuracy and speed will drive the next set of updates.
Long-Term: Evolution
If the initial tests are successful, I plan to:

  • Upgrade the Listener: Integrate a more advanced voice model to handle even noisier environments and more diverse accents.
  • Expand the Library: Add support for more Bible versions while ensuring all copyright requirements are met.
  • Scale the System: Optimize the backend to support thousands of churches simultaneously, moving from a single-service tool to a broad-scale platform.