Everything written more than a month ago is already lost

Hagah is a product for people who study Scripture by hand and keep the notebooks. It is in build, targeting a validation cohort before an open beta, and it is aimed specifically at readers in Nigeria and West Africa rather than at a general English-speaking app market.

The name is the Hebrew word usually translated as to meditate, or to mutter over something repeatedly. That is the behaviour the product is built around: not reading once, but returning.

Bible apps solve reading. Not one of them solves the artefact the reader produces. Someone who studies with a physical Bible and writes by hand accumulates notebooks that cannot be searched and do not survive: everything written more than a month ago is functionally lost, even though they still own it and could point at the shelf it is on.

The obvious response, an app that asks them to type their studies instead, solves the search problem by deleting the practice. The handwriting is not an inconvenience wrapped around the content. For this reader it is a large part of the point.

• Android-dominant, mid-range devicesThe target reader is not on a recent flagship. Anything that assumes generous memory or a fast processor is not shipping to this market.
• Data is metered and connections dropPhotographs are the heaviest thing this product handles, on the connections least able to carry them. Capture cannot depend on being online.
• The content is genuinely privateA study journal can carry a confession about a named person. Privacy here is not a compliance checkbox, it is the reason someone does or does not write honestly in the app.
• The core loop has to be freeA paywall in front of archiving your own notebook kills the product in this market. Everything downstream is shaped by that.

Two users, and they are not the same person. The primary user is an individual who studies with a physical Bible and writes by hand, and who has to get full value from the product with nobody else on it. The secondary user is an existing study group that already meets, for whom sharing is the point.

Sequencing follows from that: the personal archive has to be complete and worth using alone before any group feature ships, because a product that only works once your friends join is a product that never starts.

The product is defined by a written specification rather than by feature intuition, and the part that does the most work is a table mapping each principle to the mechanism that enforces it. A principle with no enforcement mechanism is a preference, and preferences lose to deadlines.

Three ways in, all producing one kind of thing. A study can mix pages: two photographed pages and a typed reflection is a single study, not three records.

Typing is the on-ramp and handwriting is the soul, and that tension is deliberate. Typing lowers the barrier to a first study, but typed notes are what every other app already has. If the ratio collapses toward typed in beta, the honest reading is that we built a note app, which is why the handwritten share is a headline metric rather than a curiosity.

1. option 01Photograph only, or multiple ways inPhotograph-only is the purer product and makes recognition a blocker on every screen. Adding typing and pasting means the archive, search and sharing can all be finished and validated independently of it.
2. option 02A web app, or a native Android appNative gets better hardware access and a store listing. On the web, a shared link is the product: someone reads a friend's study, and they are already inside the app rather than being asked to install one first.
3. option 03Recognition that can guess, or recognition that cannotA model that writes fluent prose will quietly smooth a scrawled doubt into tidy devotional language. For a personal journal that is the one unacceptable failure, so the product uses recognition that returns noise when it cannot read something, rather than something plausible.
4. option 04Licensed translations, or public domainThe translations most read in this market are licensed. Starting with public-domain text means no licensing negotiation and no cost per reader, which is what keeps the core loop free.

• A web app, accepting weaker offline support on iPhoneThe web choice costs some background behaviour on iOS. The market is Android-dominant, so iPhone users get a degraded offline experience rather than a broken product, and that trade was recorded up front instead of discovered in beta.
• Slower to a first study, faster to a finished productBuilding three capture paths before polishing any one of them delays the impressive demo and means the archive, search and sharing are real before recognition is even decided.
• Two share modes instead of one buttonSharing an image publishes nothing. Sharing a link makes a study publicly readable. Collapsing those into one control would be simpler and would let someone make a private journal public without understanding they had done it, so they stay separate and the heavier one carries the heavier confirmation.
• AI kept out of the readingA deeper-study layer exists, but it is opt-in, per study, and never appears before the reader has looked at their own work. Understanding first, assistance second, even though surfacing it automatically would show the feature off better.

Milestone sequencing follows the strategy: everything that does not depend on reading handwriting gets finished first, so the product is validated in pieces rather than all at the end.

1. 01. FoundationsAccount, data model, and the privacy rules the rest of the product is held to. Shipped.
2. 02. Typed studies, end to endEditor, paste, autosave, reference detection, and the study view. Shipped.
3. 03. Archive and searchLibrary, timeline, full-text search, and filtering by reference, working offline. Shipped.
4. 04. Photograph captureCamera capture, compression, offline queue, and sync on reconnect. In build.
5. 05. The full study viewCorrection, tap-to-highlight between text and page, and free editing with the original restorable. In build.
6. 06. Scripture and sharingVerse lookup and revocable public links are working. Image sharing is the remaining piece.
7. 07. Groups, then deeper studyInvite codes, shared studies, threaded comments, then the opt-in study layer. Next.

What the reader actually gets, in three layers: the study itself, the archive it joins, and the ways it can leave.

The shared image is the photograph of the page, not a generated quote card. A group feed that looks like people's actual notebooks is the thing no other Bible app produces, and it is also the strongest reason anyone outside the product ever hears about it.

Pre-beta, and stated as such. The personal loop works today: a study can be written, saved, searched, found again, and shared as a revocable link, offline and on a real device. The photograph path and group features are in build.

The next checkpoint is a validation cohort targeted at around week six, with an open beta targeted around week ten. There are no traction numbers here because there are no users yet, and any figure in the metrics below is a target the product will be judged against rather than a result it has produced.

These are targets, not results. The handwritten share is the one that decides whether the product is what it claims to be: if most studies arrive typed, the honest conclusion is that we built a note app and the premise was wrong.

• ›Taking the hardest capability off the critical path changed the whole schedule. Once typed studies existed, the archive, search and sharing could all be built and validated without waiting on a recognition decision.
• ›A principle needs a mechanism or it is decoration. Writing each product principle next to the specific thing that enforces it is what stopped "do not alter the user's meaning" from being a nice sentence in a document.
• ›A metric that can falsify the product is worth more than one that flatters it. The handwritten share is defined so that failing it means the premise was wrong, which is the only kind of number worth setting in advance.
• ›Distribution is a product decision made early or not at all. Choosing the web meant a shared study is already the app, and that shaped the build rather than being bolted on as a growth idea afterwards.