Hagah: a preservation layer for handwritten Bible study

Hagah, from the Hebrew for “to meditate, ponder, and preserve,” is my answer to a problem I have watched play out in my own notebooks and in the notebooks of people I study Scripture with: handwritten Bible study is the deepest kind, and the most fragile. A drop of water, a lost bag, a decade of shelf life, and years of thinking are gone.

I built Hagah as a product builder, end to end: product definition, UX, and the full application, a camera-to-archive pipeline that photographs a handwritten study page, transcribes it verbatim with Google Gemini's vision model, structures it into typed study blocks, and files it into a searchable personal archive, alongside a KJV/WEB Bible reader and a Scripture-anchored fellowship space.

Existing Bible apps digitise typed notes. None of them take a photograph of a physical notebook page as the primary artifact. And existing OCR and note-taking tools are built to “clean up” handwriting: correcting grammar, paraphrasing, summarising. For a personal theological reflection, that is the opposite of what is wanted. A misread word silently corrected is not a convenience, it is a changed thought.

The result is a body of work that stays trapped in physical notebooks: unsearchable, undiscoverable, and one accident away from being lost entirely, even though the person who wrote it would want nothing more than to find what they wrote about Romans 8 three years ago.

• Verbatim above allThe one rule that shapes every AI prompt in the system: never alter, correct, or paraphrase the user's personal thoughts or theology. Every extracted block must verbatim reproduce a portion of the user's note.
• A companion, not an authorityThe Theological Inquiry feature has to read as clearly subordinate to the user's own study and prayer, and fair across Christian traditions rather than picking a side on disputed interpretation.
• Contribution before consumptionCommunity and public discovery cannot be the default. A user has to preserve one study of their own before they can browse or discuss anyone else's, which is a product constraint, not a technical one.
• Graceful without a keyThe app has to remain usable, transcription, tagging, sharing, all of it, when no Gemini API key is configured, falling back to deterministic heuristics rather than breaking.

One core user: a person who studies Scripture by hand, alone or as part of a small group, church study circle, or family devotional. Around them, the fellowship layer introduces a second role, the reader of someone else's preserved study, who arrives through a shared group code or a public share card rather than an open feed.

As the product builder I also built for the model itself as a constrained participant: Gemini is treated throughout as an extraction and structuring engine operating under strict rules, never as an editorial voice with license to interpret.

The starting observation was personal: my own handwritten study notebooks, and the notebooks of people around me in Bible study, hold years of thinking that never leaves the page. Nobody searches a shelf of notebooks for what they wrote about Genesis 50:20. The gap was not a lack of digital Bible tools, it was that none of them started from the physical page as the object worth preserving.

That reframed the product question from “how do we help people take better digital notes” to “how do we preserve the notes people already trust enough to write by hand,” which is why the Original Notebook view, the actual photographed page, is the first tab on every study, not the transcription.

Preserve the artifact first, structure it second, and only then open a door to community. Every study keeps its photographed page as the primary record; the AI layer adds a verbatim transcription and a structured reading on top of it, never in place of it. Nothing about the underlying note changes when AI assistance is added or removed.

Fellowship was deliberately built as the last layer, gated behind a first preserved study, so the product's center of gravity stays on personal study rather than becoming a feed to scroll before anyone has written anything of their own.

• option 01General-purpose note OCR vs a purpose-built promptA general handwriting-to-text API would have shipped faster. Chosen instead: a Gemini prompt written specifically as Hagah's transcription and structuring engine, with explicit verbatim rules and a fixed response schema, so extraction and theological block classification happen in one grounded call.
• option 02Open community by default vs contribution-gated fellowshipOpening Fellowship to every new signup would show more content sooner. Chosen instead: a hard gate on one preserved study, because a study app that leads with other people's content teaches the wrong habit from day one.
• option 03AI-polished summaries vs strictly grounded onesLetting the model write a flattering, embellished share summary would look better in isolation. Chosen instead: every generated summary and every structured block is explicitly instructed to draw only from the user's own text, with a heuristic fallback that truncates rather than invents when no summary can be grounded.

• Friction over false completenessRequiring a first preserved study before Fellowship unlocks means some visitors never see the community layer at all. That friction is intentional: it is the mechanism that keeps the product a study tool first.
• A fallback path over a single happy pathEvery AI-backed endpoint, OCR, tagging, theological inquiry, share summaries, ships with a deterministic heuristic fallback. That is real engineering surface area for a feature that, ideally, never triggers, bought so the app degrades instead of breaking when a key is missing or a call fails.
• Restraint over depth in Theological InquiryThe feature could go further: saved inquiry history, denomination-specific modes, longer essays. It was deliberately kept to context, cross-references, multi-tradition perspective, and reflection questions, framed explicitly as secondary to the user's own study.

Built solo as a working prototype: capture and OCR pipeline first, then the structured archive and Bible reader, then the fellowship and sharing layers on top. Each layer was shipped only once the one beneath it worked end to end with a real photographed page, not a placeholder.

A photographed page is sent to an Express endpoint, which calls Gemini with a fixed response schema: detected Scripture references, suggested study tags, and an array of typed blocks (scripture reference, observation, question, cross-reference, key point, or reflection), each required to hold a verbatim excerpt of the source note. Word-level confidence scoring flags uncertain OCR reads for the writer to confirm rather than silently trusting them. If no Gemini key is configured, or a call fails, the same endpoint falls back to deterministic heuristics, keyword and pattern-based block classification and tag suggestion, so the product degrades gracefully instead of breaking.

The full loop works end to end: photograph a notebook page, review a verbatim transcription with confidence flags, see it organised into structured study blocks, tag it, search it alongside every other study in the archive, and once a first study is preserved, discuss it inside Scripture-anchored fellowship groups or share it as a generated card, with a mandatory preview so a private reflection is never exposed by accident.

Screenshots below are from the working prototype: the archive, a study opened across its Original Notebook, Verbatim Text, and Structured Blocks views, the Bible reader, Fellowship, Theological Inquiry, and the Share Study Card flow.

‹

Click to expand

Click to expand

Click to expand

Click to expand

Click to expand

Click to expand

Click to expand

Click to expand

Click to expand

›

• ›A single non-negotiable rule, "verbatim, never paraphrase," is worth writing directly into every prompt rather than trusting a model's default helpfulness, which naturally drifts toward smoothing and summarising unless explicitly told not to.
• ›Gating a feature behind user contribution is a product decision with real UX cost, not just a growth lever. It has to be justified on what it protects (here, a study-first product identity), not on engagement metrics alone.
• ›A fallback path is not optional for an AI feature meant to feel trustworthy. Designing the heuristic classifier and deterministic summary truncation took real effort for a path that, ideally, rarely runs, and that effort is what keeps the product honest when the model is unavailable.