DEV Community: Nova Lumen Labs

What happens to your domains and cloud logins if you disappear? Building an encrypted vault for solo founders

Nova Lumen Labs — Wed, 11 Nov 2026 10:57:00 +0000

If you run a company alone, a lot of it lives in one head: the registrar login, the payment processor, the cloud account, the app store accounts. If something happens to you, nobody knows those exist, let alone how to get in. I built Heirloom: Founder Vault to deal with that, and this post covers the design choices.

What it does

You record the important accounts and assets, and name up to 5 beneficiaries who get read-only access only when you can't respond. That's the whole idea. It's closer to a binder for your successors than a password manager.

Stack

React Native with Expo (no native folders checked in), WatermelonDB for local storage, Expo SecureStore and local authentication for biometrics, Supabase on the backend, RevenueCat for purchases.

Encryption of exports

For encrypted exports I use AES-256-GCM, which is authenticated encryption, so tampering is detected rather than silently decrypting to garbage. The key comes from your passphrase through PBKDF2-HMAC-SHA256 with 210,000 iterations (OWASP's 2023 guidance for that KDF) and a random 16-byte salt per export. The libraries are @noble/ciphers and @noble/hashes, which are audited and pure JS, so there's no native crypto module to maintain. The KDF parameters are stored beside the ciphertext so older exports stay readable if I raise the iteration count later.

The hard part is not crypto

The hard question is the trigger: how do you decide someone really can't answer, without false alarms and without being gameable? The app is built around a regular check-in: you confirm you're fine, and access only opens when check-ins stop. I would not call the trigger design solved. I'd like opinions from people who have thought about dead-man's-switch design.

Links (I'm the developer)

Disclosure: I used an AI assistant to help draft and edit this post; the technical details come from the app's source code.

Building a document scanner where OCR never leaves the phone (VisionKit + Vision + PDFKit)

Nova Lumen Labs — Wed, 11 Nov 2026 10:49:45 +0000

Most free document scanners upload your pages to a server for text recognition. Passports, tax forms and receipts included. There's no technical need for that on a modern phone, so I built LumenScan as an experiment in doing all of it locally. This is how it's put together.

The stack

Capture: VNDocumentCameraViewController from VisionKit, the same component Apple Notes uses. You get live edge detection, auto-capture, multi-page flow and a corner editor for free. I first wrote a custom AVFoundation camera, then dropped it as the main path; it now only runs on simulators or devices without Apple's scanner.
OCR: the Vision framework's text recognition, on device. I set it up to cover English plus Hindi, Tamil and Telugu, since the first target market was India.
PDF: PDFKit builds the output and handles annotation and signing. The recognized text is laid under the page image so the PDF is searchable.
History: SwiftData.
Purchases: RevenueCat, with prices read from StoreKit so the storefront currency shows correctly instead of being hard-coded.

Analytics without betraying the pitch

If the pitch is that nothing leaves the phone, analytics has to be careful. I send only a fixed list of explicit event names, with no autocapture, no session replay, and never document content. The analytics SDK does nothing at all until a real key is configured.

One bug worth sharing

Cancelling Apple's scanner sheet used to open my fallback camera right behind it, so users saw a second camera after backing out. The fix was to treat cancel as closing the whole scan flow. Obvious in hindsight; I only found it by using the app like a user rather than by reading code.

Business model, honestly

Free scans each day, with Pro for unlimited scans, Word export, password-protected PDFs and signing. There is a 7-day trial. Prices vary by storefront.

Feedback wanted

If you've shipped Vision OCR for non-Latin scripts, I'd like to compare notes on accuracy with low light and skewed pages.

Links (I'm the developer):

Disclosure: I used an AI assistant to help draft and edit this post; the technical details come from the app's source code.

Why a plain FFT tuner locks onto the wrong note, and what I used instead (McLeod Pitch Method on iOS)

Nova Lumen Labs — Wed, 11 Nov 2026 10:49:10 +0000

I'm a solo developer at a small studio, and I recently shipped a guitar tuner and metronome called Maestro. The tuner was the part I got wrong first, so this post is about that.

The naive approach fails on real instruments

The obvious way to build a tuner: take a window of microphone samples, run an FFT, pick the tallest peak, convert to a note. It works on a sine wave. On a real guitar it doesn't, because the loudest bin is often the 2nd or 3rd harmonic, not the fundamental. A low E (about 82 Hz) will happily read as the E an octave up, or as a B, depending on the pluck.

What I used: the McLeod Pitch Method (MPM)

MPM computes a normalized square-difference autocorrelation of the window. Instead of looking for the biggest peak in frequency space, it looks for repeating structure in time, and normalizes by signal energy at each lag so quiet tails don't lose to loud attacks. Then it picks the first strong peak, which is the fundamental, and refines it with parabolic interpolation for sub-sample precision (this is what gets you to a fraction of a cent).

A few practical details from the implementation:

Range: roughly 30 Hz to 2 kHz, so a 5-string bass low B and a violin's top register both fit. A 4096-frame buffer holds more than two periods at 30 Hz, which keeps the autocorrelation meaningful.
Two gates before accepting a result: an RMS floor (so digital silence and room hiss don't run the expensive part) and a clarity threshold on the normalized peak height (I use 0.6) so breath noise doesn't show a phantom pitch.
The heavy loops go through Accelerate's vDSP, so analysis fits inside one tap callback (about 93 ms of audio) even on older phones.
The detector is a pure function: samples plus sample rate in, optional frequency plus clarity out. That made it easy to unit test against synthesized sine waves, with no microphone involved. Smoothing and note-name math live in a separate tracker.

The metronome and the rest

The metronome covers 40 to 240 BPM with tap tempo and haptics, and there is a practice log with streaks. The tuner and basic metronome are free; a Pro tier adds extra tunings, insights and export. It is on iOS and Android.

What I'd still like feedback on

Percussive, very low notes on cheap phone mics are the hardest case for me. If you build audio tools and have seen better gating for that, I'd like to hear it.

Links (I'm the developer):

Disclosure: I used an AI assistant to help draft and edit this post; the technical details come from the app's source code.