What I learned building a local-first password manager with Flutter

niluved — Sat, 20 Jun 2026 17:19:06 +0000

I used to keep my passwords in a password-protected, zipped Word document. Stored locally on my PC, with a backup copy on a USB drive.

Every password update required opening the file, entering the master password, editing the entry, syncing the change to the USB backup manually. Repeat.

On my phone? Even worse. I had to boot up the PC, unzip, search, update, re-sync — every single time.

That system worked… until it didn't. I realized I was one hardware failure away from locking myself out of everything. I needed a mobile solution, but with one non-negotiable constraint: my passwords were never leaving my device.

So I built Keyri.

Play Store: https://play.google.com/store/apps/details?id=com.nick.applab.silentsaver

Stack

Flutter (cross-platform UI, single codebase)
ChaCha20 for on-device encryption
Google ML Kit for on-device QR/barcode scanning (optional)
HaveIBeenPwned API with k-anonymity for breach checks (optional)
XposedOrNot API for account breach details (optional)
Brandfetch API for real logo icons (optional)
Google Drive integration for storing encrypted data (optional)

The constraints that shaped every decision

No cloud = no server = no trust required. That wasn't a feature list — it was the starting point. Every technical choice follows from it.

Encrypting images on-device

I wanted users to store sensitive images (IDs, receipts) inside the vault. Images are compressed on-device, encrypted with ChaCha20, and stored in the app sandbox. The decryption key never leaves the device memory unencrypted.

Breach checks without exposing passwords

I integrated HaveIBeenPwned, but with a hard constraint: the actual password never leaves the device. The solution is k-anonymity — only the first 5 characters of the SHA-1 hash are sent. The server returns a list of matching hash suffixes, and the match is checked locally (standard approach)

Flexible CSV import

I recently rewrote the importer to auto-detect the 5 main credential fields (username, password, URL, title, notes) regardless of column order or naming. It now accepts a wide variety of CSV structures without requiring the user to manually map columns.

One-click autofill via Android's native framework

I wanted logging into websites to feel frictionless — ideally one tap from the browser, no copy-paste. The cleanest way is Android's Autofill Framework, but Flutter doesn't expose it directly.

To make Keyri participate in the system autofill service, I had to drop down to native Android code. I wrote a Kotlin service that integrates with the Autofill API and communicates with the Flutter side via method channels. I didn't know Kotlin before this project — I learned it specifically to implement this feature, with a lot of help from Copilot along the way tbh ;)

The result: Keyri appears as an option in Android's autofill picker, and credentials fill in-app and in browsers with a couple of taps. All parsing of the target app/website structure happens on-device; nothing is transmitted.

Google Drive backup — still local-first

I just rolled out optional Google Drive backup. The challenge was keeping the local-first philosophy intact.

The solution: data is encrypted on-device before upload. The backup file is useless without the app's master key, which never leaves the device unencrypted. Even if Google wanted to hand over the file, it would be encrypted gibberish without the user's credentials.

No account is created. The Drive integration uses the user's existing Google account via OAuth.

What Keyri does today

Local-first vault: passwords, cards, barcodes/QR codes, encrypted images
Biometric unlock (fingerprint/face)
Android Autofill integration
Local breach checks (k-anonymity, no data sent)
Encrypted backups (Google Drive optional)
Flexible CSV import from any major password manager
Zero ads, zero tracking, zero accounts required

A few questions (no trust required)

I'm aware that a closed-source password manager from a solo dev isn't the easiest sell in the privacy community. I'm not here to ask for your trust — I built this to fix my own Word-document disaster, and I'm sharing it in case you're in the same boat.

If you're willing to evaluate it on its own merits (or just curious about the build), I'd love to hear some feedback.
What's the one feature that would make this actually usable for you? What's the one thing that would make you walk away?

Thanks for reading so far!

My homescreen was chaos. Not anymore.

niluved — Sat, 20 Jun 2026 16:22:11 +0000

I built an Android widget that learns your app habits — without sending anything to a server

I had a problem. My home screen was organized chaos: folders for Work, Music, Streaming, Chat, Hobbies. Every evening I’d open the same three folders in the same order just to launch the same handful of apps. I wasn't finding apps — I was repeating a ritual.

My phone already knows what I do and when I do it — it just never puts that knowledge to use. So I built Habits to teach it to repeat what it has already seen.

The constraint: Android only remembers a few days

The predictive feature needs the Usage Access permission. The problem? Android only retains raw usage history for a few days by default. After that, the data is gone.

I needed enough history to recognize actual patterns — not just what I opened yesterday, but what I open at 8 AM on a typical Tuesday. That requires weeks of accumulated history, and Android doesn’t give you that out of the box.

I also wasn't willing to ship app usage logs to a backend. This widget was going to be smart, but only if it could be smart without touching a server.

How it works under the hood

Habits accumulates usage history on the device — timestamps, durations, which apps — storing it for long enough to smooth out noise and detect recurring patterns. A statistical model then correlates the current time slot with past behavior to assign relevance scores to installed apps.

The model balances two signals:

Long-term habits (default weight: 75%): apps you tend to use at this time of day over the past weeks
Short-term context (default weight: 25%): apps you opened in the last few minutes, which suggest what you’re about to do next

You can adjust the relative weight of each factor in settings, so the widget adapts to how predictable your routine actually is.

What the widget actually does

Surfaces apps contextually: morning coffee → news apps, Friday evening → streaming and music
Customizable grid (columns/rows) directly in widget settings
Monochromatic icon support natively — no third-party icon packs needed
Material You dynamic colors, custom backgrounds, adjustable icon sizes
Pin/exclude apps: keep essentials always visible, hide outliers
Full icon pack support if that's your setup
Export/import your history: the usage database can be exported and re-imported on a new device — your model follows you, no lock-in

The honest version (the stuff I'd want to know before installing)

Usage Access is required — the core feature doesn't work without it. The app prompts for it on first launch.
No accounts, no IAP, no ads — but also no cloud sync, no server fallback.
No magic: the predictions are based on patterns in your own history. If your habits are genuinely unpredictable (shift worker? seasonal routine?), the widget won't help much.

Stack

Kotlin, native Android
Jetpack Compose + Glance widget
Apache Commons Math for the statistical model
Local DataStore for historical usage accumulation

Feedback wanted

This is my first attempt at on-device predictive UX. Two things I'm actively grappling with:

Model scope vs. accuracy: I'm deliberately keeping the model narrow (time-based patterns) to avoid permission sprawl. I'd love to hear from others who've tried adding signals like location or calendar overlap — what worked, what broke the battery.
Detecting "out of pattern" periods: The model learns habits, but habits break. Vacations, travel, sick days — how do you signal to an on-device model that "this week is different" without adding heavy heuristics or extra permissions? I'm wary of turning this into a full scheduling system, but ignoring those periods makes predictions worse for a chunk of the year.

I'd love to hear from other Android devs — especially anyone who's hit the Android usage history wall or tried on-device prediction.

Play Store: https://play.google.com/store/apps/details?id=com.nick.applab.habits

DEV Community: niluved

What I learned building a local-first password manager with Flutter

Stack

The constraints that shaped every decision

Encrypting images on-device

Breach checks without exposing passwords

Flexible CSV import

One-click autofill via Android's native framework

Google Drive backup — still local-first

What Keyri does today

A few questions (no trust required)

My homescreen was chaos. Not anymore.

I built an Android widget that learns your app habits — without sending anything to a server

The constraint: Android only remembers a few days

How it works under the hood

What the widget actually does

The honest version (the stuff I'd want to know before installing)

Stack

Feedback wanted