So I built Forgepost: a self-hosted blogging engine whose whole point is the publish → measure → experiment → improve loop. It’s a small blog that treats every headline, paragraph, image, and call-to-action as a measurable, testable object. You write in Markdown, publish, watch where readers drop off, then A/B test alternative content on a single block and let a Bayesian engine decide when a variant is a clear winner. Version 0.1.0 just shipped.

A blog you can test

At its heart Forgepost is a tiny blogging engine. A Markdown editor parses your post into an immutable block tree — heading, paragraph, image, quote, code, call_to_action, divider. Each block is a versioned object, and that’s what makes experimentation possible: an experiment is just “show some visitors a different version of one block.”

Saving sets the public URL from the title while the post is still a draft; once published, the URL is stable. Publish and the post appears on the public route and the RSS feed. That part is deliberately boring — the interesting stuff happens after you publish.

Measuring without creeping

Analytics on the web has a habit of being invasive. Forgepost takes the opposite approach: the tracking script reports banded scroll depth (25, 50, 75, 100%), article completion, read time, and per-block impressions through a rate-limited API. No raw scroll streams, no personal data, no third-party cookies — just enough to rebuild the reading experience afterwards.

From that you get per-article stats (views, unique readers, average reading time, completion, a scroll-depth funnel) and a per-block drop-off table: this is exactly where readers leave. Every estimated number is labeled as estimated, because ad blockers and JS-disabled readers are undercounted by design. A recent wave added traffic sources (Search / Direct / Community per article), share tracking (a Share button that reports click events), and “Keep reading” — up to three related-post cards ranked by shared tags, with impressions and clicks tracked for a future recommendation engine.

The Bayesian engine

The interesting technical core is forgepost-experiments, a pure Rust crate with no I/O. When you A/B test a block, each variant gets a stable per-visitor share of traffic, and the engine tracks impressions and conversions. The goal model is deliberately single: a “completion” is a visitor who scrolled to the end of the article.

Under the hood it’s a Bayesian sequential test with exact P(beats control) from beta posteriors, equal-tailed credible intervals, and a confidence threshold that’s corrected for spending — so peeking at the results a thousand times doesn’t fool the threshold the way naive repeated significance testing would. There’s also a no-winner stopping rule: when a variant is near-certain to lose, the test concludes “no improvement” instead of waiting forever.

A background auto-decider polls running experiments and applies the rules automatically — promoting the winning variant once it clears the threshold, or concluding no improvement. A decision repoints the live block to the winning immutable version, so the article updates immediately. The correctness story is solid: golden tests with hand-computed beta probabilities plus property tests for posterior sanity, sample-size concentration, and assignment honesty.

One binary, one command

Forgepost is a single Rust binary with an embedded SQLite database. There is no Node.js server in production, no separate database server, no reverse proxy required — the binary terminates HTTPS itself, either with certificates you bring or with automatic Let’s Encrypt issuance and renewal via TLS-ALPN-01 (no port 80 needed for issuance). Deployment is one command:

sudo ./install.sh blog.example.com

That script installs build deps and Rust, clones and builds the release binary, creates a locked-down runtime user, writes the config, installs systemd units, and opens the firewall. A nightly backup service runs forgepost export — a JSON dump of the whole database, experiments and decisions included — alongside a tarball of your uploaded media, pruned by retention. For the release I also added deploy tests that boot the binary from the install script’s own env-file keys and run the real backup script against a throwaway database, plus a check that the scripts still point at the real repository — the kind of thing that breaks silently and wakes you up at 3 a.m.

What I’d tell myself

• A single goal model is a feature. One “what did the reader do at the end?” measure keeps the experiment engine simple and the dashboard honest. Custom goals can come later; the MVP is better for not having them.
• Honest labels beat clever algorithms. Admitting that blockers make numbers an underestimate is what makes the rest of the product trustworthy.
• Self-hosting is the whole brand. No telemetry, no signup to read, no third-party anything. The data is a SQLite file you can back up with forgepost export and delete whenever you like.

Forgepost is AGPL-3.0. The single binary is attached to the v0.1.0 release, and the docs site walks through install, setup, and the experiment workflow. If you’ve ever wanted your own writing to get the treatment the big platforms reserve for their paying customers, give it a shot.

Source: github.com/DavidNeurieder/Forgepost (AGPL-3.0)

So I built LibreCrate: an encrypted document vault that runs on Android, Linux, macOS, and Windows, with a core written once in Rust. It stores PDFs, EPUBs, Apple Wallet passes, CBZ comics, images, and Markdown notes. Every file is encrypted at rest, the app has zero network access, and your data moves between devices through encrypted backups — never through a cloud.

One Rust core, three frontends

The decision that shaped the whole project: instead of writing the crypto, database, and backup logic once per platform, everything lives in a single Rust crate called vault-native. Three frontends talk to it:

• Android — Kotlin + Jetpack Compose, bridged through Mozilla’s UniFFI. The Gradle build compiles the Rust library and generates the Kotlin bindings automatically; the app never touches a byte of crypto directly.
• Desktop GUI — Iced, a native Rust GUI framework. The same vault, library, readers, and settings on Linux, macOS, and Windows.
• CLI — a small terminal app with an interactive REPL: init, import, list, search, backup, restore, plus readline history and tab completion.

One codebase handles encryption, the SQLCipher database, merging, and backup. Fix a bug in the core and every platform gets the fix. The UI layers only ever see a clean FFI surface.

Encryption at rest

• Per-file encryption — AES-256-GCM with a 12-byte IV and 128-bit tag
• Key wrapping — the master key is wrapped via Argon2id + AES-256 Key Wrap (RFC 3394)
• Optional password mode — even with the device unlocked, nothing is readable without the password; otherwise the master key is wrapped with a per-device key
• Zero network — there is no internet permission in the manifest. Not “we promise not to phone home” — the app literally cannot.

A library you can actually search

The vault remembers your reading position per document — last page for PDFs and comics, last location for EPUBs — and shows “Page X of Y” right on the library cards. Filtering by type, favorites, and sort order round out the library view.

The killer feature for me is full-text search. FTS5 indexes title, author, description, and the extracted text inside each document, with highlighted snippets in the results. I can search all my PDFs for a phrase I half-remember and get the matching document with the surrounding text highlighted. It feels like owning my own little search engine — no cloud, no telemetry.

Backups that merge

Backups are a single encrypted .librecrate-backup file containing the wrapped master key, the database, and every document. Because the format is shared between Android and desktop, a backup made on your phone restores on your laptop and vice versa.

The newest behavior (0.5.4) is that import merges instead of replacing. In the past, importing a backup rebuilt your library from scratch — anything local that wasn’t in the backup was gone. Now the backup’s documents are added on top of your existing library: your documents stay, the backup’s content joins them, and conflicting versions are flagged instead of silently overwritten. Your local passkey stays exactly as it is — only the backup’s own passkey is needed to decrypt it, and backups created with a different passkey can be merged too (their files are re-encrypted with your local key). Merged documents are searchable immediately.

Chasing reproducible F-Droid builds

LibreCrate is F-Droid-only by design — no Play Services, no Firebase, no Crashlytics. That means the F-Droid build farm compiles the native Rust library itself, and it requires the resulting APK to match mine byte-for-byte. This has been the most humbling part of the project.

The native library builds MuPDF from source, which initially produced subtly different binaries on different machines. The fixes were a real scavenger hunt: deterministic source ordering in the MuPDF C wrapper, --remap-path-prefix to strip every local build path from the binary, a pinned Rust toolchain, an OpenSSL ranlib fix for the NDK, and most recently gating MuPDF’s system-font support behind a desktop-only feature so the F-Droid host build no longer needs system fontconfig. Each fix is one more variable eliminated, and the local build now matches F-Droid’s — apart from the git revision F-Droid embeds, which is expected.

The recipe is ready; the build farm just keeps finding new ways to break my weekend. That’s the F-Droid way, and honestly I’d rather have it than trust a binary blob I didn’t build.

Try it

If you’ve ever wanted your documents to live only on your devices — readable, searchable, and encrypted — give it a shot.

• Android: install the APK from the GitHub releases
• Desktop: prebuilt binaries for Linux/macOS/Windows, or cargo install --path vault-native/gui
• CLI: cargo install --path vault-native/cli

Source: github.com/DavidNeurieder/LibreCrate (AGPL-3.0)

That’s worse than a crash. A crash is loud — you know something broke. A silent success that does nothing leaves users thinking the feature works while they have nothing to show for it.

I found three of these bugs in Activity Trace. Here’s how I fixed them, plus the statistics screen rewrite and database migration that came along for the ride.

How exports were silently failing

Activity Trace lets you export captured clipboard content as JSON, CSV, or a plain SQLite database. The code used Boolean as the return type — true for success, false for failure. Simple.

But the gap between “the function returned” and “the file exists” was wide enough to drive a truck through.

Bug 1: Null output stream

MediaStore on API 29+ works by inserting a content URI, then opening an output stream on it. If openOutputStream returns null — which happens when another app has a lock on the file or the content resolver rejects the URI — the old code just returned false without writing anything. But the calling code checked if (!writeToDownloads(...)) and threw if false. If openOutputStream returned null, writeContent got a null stream, returned false, and the caller threw. So this was caught — but only on the code path that checked the return value.

The real problem was the database export path. It didn’t check the return value at all. It used the same pattern but ignored the result, making it a silent no-op.

Bug 2: Stale temp files

DatabaseExporter.exportToPlainSqlite creates a temporary SQLite file, attaches it to the encrypted Room database, and runs sqlcipher_export to copy data into it. If a previous export crashed, the temp file survived with its schema intact. The next run would try to ATTACH DATABASE to the existing file, find it already has a captured_items table, and fail with “table captured_items already exists”.

The fix was a single line: outputFile.delete() before opening the new database. Plus a finally block to clean up after ourselves.

Bug 3: No diagnostic logging

When the export did fail, the user saw “Export failed” with no way to figure out why. I added ExportErrorLogger — a utility that writes the full stack trace to Download/ActivityTrace/export_error_<timestamp>.log using MediaStore (API 29+) or the legacy file API, with a fallback chain all the way down to filesDir/ActivityTrace/.

Along with that I replaced the Boolean return type with a sealed class:

sealed class ExportStatus {
    data class Success(val message: String) : ExportStatus()
    data class Error(val message: String) : ExportStatus()
    data class Progress(val message: String) : ExportStatus()
    data class Cancelled(val message: String = "") : ExportStatus()
}

Now every caller must handle all four cases. No more “returned true but did nothing.”

Database migration for system app blocking

Activity Trace lets you block certain apps from being captured. By default, system apps like the keyboard, launcher, and settings should be blocked so they don’t clutter your history.

The list lived in CaptureIngestor.kt as DEFAULT_BLOCKED. But when the database needed to seed these defaults on first run, it created a circular dependency — the database module shouldn’t know about the capture module.

I extracted the constant to a standalone file:

// BlockedAppDefaults.kt
internal val DEFAULT_BLOCKED = setOf(
    "com.android.inputmethod.latin",
    "com.android.systemui",
    "com.google.android.apps.nexuslauncher",
    // ... 4 more
)

Then bumped the database version to 6 and wrote a migration. Here’s where it got tricky.

Room migrations with SQLCipher run through SupportSQLiteDatabase, which is a wrapper around the encrypted database. The execSQL method does not support ? bind arguments. I spent an hour wondering why execSQL("INSERT INTO blocked_apps(app_package) VALUES(?)", arrayOf("com.android.inputmethod.latin")) wasn’t working. It just silently inserted nothing.

The fix: inline the values as string interpolation. Ugly, but it works:

fun seedDefaultBlocked(db: SupportSQLiteDatabase) {
    for (pkg in DEFAULT_BLOCKED) {
        db.execSQL("INSERT OR IGNORE INTO blocked_apps(app_package) VALUES('$pkg')")
    }
}

The migration and the RoomDatabase.Callback.onCreate both call the same function, so fresh installs and upgrades behave the same way.

Unifying the statistics screen

The statistics screen had two layouts depending on whether you selected a single app or viewed all apps. If you selected one app, it showed a different set of charts below the summary cards. Switching between tabs would change the chart height, causing a visual jump as content shifted around.

I removed the conditional layout entirely. Now every view shows:

SummaryCards → Top apps → Timeline → Content type breakdown

No matter what filter you apply, the structure stays the same. The charts all use a unified 160dp height, so switching between the Daily, Hourly, and Day-of-week tabs doesn’t move anything.

While I was in there, I fixed an overlapping label issue in DailyChart. When a bar is short (fewer than 32 pixels), the count label drew on top of the date label below it. The fix: draw the count label inside the bar when the bar height is too small — otherwise it switches to the default position above the bar.

val textY = if (barHeight <= 32f) barTop + barHeight - 4f else barTop - 8f

Tests that caught real bugs

The export bugs were all in untested code paths. I added 14 new tests across 5 test files to cover them:

• BlockedAppDefaultsTest — Verify all 7 default packages are present
• ExportStatusTest — Exhaustive when coverage on the sealed class
• ExportErrorLoggerTest — Log file content, cause chain, null message handling
• DatabaseExporterTest — Query failure, execSQL failure, stale file replacement
• ActivityTraceDatabaseMigrationTest — MIGRATION_5_6 seeds 7 packages without duplicates

Plus a Compose UI smoke test for the statistics screen (5 instrumented tests) and an extended SettingsScreenTest that runs a full CSV→SQLite import roundtrip.

The roundtrip test immediately caught a bug I would have shipped: the CSV export used "text/csv; charset=utf-8" as the MIME type. MediaStore on Android 16 (API 36) rejects MIME types with RFC parameters. The insert returned null, the export failed, and the test turned red. Fixed by changing it to plain "text/csv".

The takeaway

Three things I’ll do differently going forward:

1. Never use Boolean as a return type for I/O operations. A sealed class with descriptive variants forces callers to handle failure, and gives users a meaningful error message when something breaks.

2. Always clean up temp files. If your function creates a file, delete it when you’re done — and delete it before you start if it already exists. Stale state from a previous run is a debugging nightmare.

3. Test the unhappy paths. The export code had been in production for months. Every code path that succeeded was tested by — well, succeeding. Every code path that failed was invisible. Write a test that makes the database throw, makes the output stream return null, makes the temp file already exist. Those tests are worth more than ten “insert item then read it back” tests.

The app is on F-Droid. If you want to try it, grab the latest build. All the fixes from this session are in v0.8.0.

Source: github.com/DavidNeurieder/ActivityTrace

But the alternative is shipping bugs to users. So here’s how to actually do it — practical, no theory, just the steps.

Three layers of testing

You need three things:

1. Unit tests — Fast, run on your machine, test logic in isolation
2. Instrumented tests — Run on a device or emulator, test UI and Android-specific code
3. Lint and type checks — Catch obvious mistakes before they become tests

Each layer catches different bugs. Skip one and you’ll ship the kind of bugs that only show up on certain devices, or only after a specific sequence of user actions.

Layer 1: Unit tests

Unit tests verify that a function does what it says. No Android framework, no database, no network. Just input in, output out.

Setting up

In your app/build.gradle.kts, make sure you have test dependencies:

dependencies {
    testImplementation("junit:junit:4.13.2")
    testImplementation("org.assertj:assertj-core:3.24.2")
    testImplementation("org.mockito.kotlin:mockito-kotlin:5.1.0")
    testImplementation("org.jetbrains.kotlinx:kotlinx-coroutines-test:1.7.3")
}

Writing a test

Pick a function that does something meaningful. If you’re building a currency converter, test the conversion math. If you’re building a search engine, test the query parser.

Here’s a concrete example — testing cross-rate computation:

class ConversionCalculatorTest {

    @Test
    fun `cross rate from non-EUR source computes correctly`() {
        // Given: EUR→USD = 0.92, EUR→JPY = 148.50
        val rates = mapOf(
            "USD" to 0.92,
            "JPY" to 148.50
        )

        // When: Converting 1 USD to JPY
        val result = rates["JPY"]!! / rates["USD"]!!

        // Then: 1 USD = 161.41 JPY
        assertThat(result).isEqualTo(161.41, within(0.01))
    }
}

Notice the pattern:

1. Given — Set up the test data
2. When — Call the function
3. Then — Verify the result

This pattern makes tests readable. When one fails, you immediately see what went wrong.

Testing with mocks

Some functions depend on databases, APIs, or other services. Mock them:

class SyncUseCaseTest {

    private val repository = mock<ExchangeRateRepository>()
    private val preferences = mock<PreferencesManager>()
    private val useCase = SyncExchangeRatesUseCase(repository, preferences)

    @Test
    fun `sync skips when last sync was recent`() = runTest {
        // Given: Last sync was 1 hour ago, interval is 6 hours
        whenever(preferences.lastSyncTime).thenReturn(
            System.currentTimeMillis() - 3600_000
        )
        whenever(preferences.syncInterval).thenReturn("6h")

        // When
        useCase()

        // Then: Repository was never called
        verify(repository, never()).fetchAndStoreRates()
    }
}

Running unit tests

./gradlew testDebugUnitTest

This runs all unit tests in about 1-3 seconds. If you’re using AI to generate code, run this after every few changes. It’s fast enough to be a habit.

Common unit test patterns

Test edge cases:

@Test
fun `empty input returns zero`() {
    assertThat(convert("", "USD", "EUR")).isEqualTo(0.0)
}

@Test
fun `same currency returns same amount`() {
    assertThat(convert(100.0, "USD", "USD")).isEqualTo(100.0)
}

Test error handling:

@Test
fun `unknown currency throws exception`() {
    assertThrows<UnknownCurrencyException> {
        convert(100.0, "USD", "XYZ")
    }
}

Test with different inputs (parameterized):

@ParameterizedTest
@CsvSource("USD,EUR,0.92", "GBP,USD,1.27", "JPY,EUR,0.0067")
fun `conversion rates are correct`(
    source: String, target: String, expected: Double
) {
    assertThat(convert(1.0, source, target))
        .isCloseTo(expected, within(0.01))
}

Layer 2: Instrumented tests

Instrumented tests run on a real device or emulator. They test the UI, navigation, and Android-specific behavior.

Setting up

dependencies {
    androidTestImplementation("androidx.test.ext:junit:1.1.5")
    androidTestImplementation("androidx.test.espresso:espresso-core:3.5.1")
    androidTestImplementation("androidx.compose.ui:ui-test-junit4")
    debugImplementation("androidx.compose.ui:ui-test-manifest")
}

Writing a Compose test

Here’s how to test that a button click navigates to the right screen:

class NavigationTest {

    @get:Rule
    val composeTestRule = createAndroidComposeRule<MainActivity>()

    @Test
    fun tappingSearchIcon_opensSearchPage() {
        // Find and tap the search icon
        composeTestRule.onNodeWithTag("search_icon")
            .performClick()

        // Verify search page is shown
        composeTestRule.onNodeWithTag("search_input")
            .assertExists()
    }
}

Testing text display

@Test
fun conversionShowsCorrectAmount() {
    // Type an amount
    composeTestRule.onNodeWithTag("amount_input")
        .performTextInput("100")

    // Wait for recomposition
    composeTestRule.waitForIdle()

    // Verify the result
    composeTestRule.onNodeWithTag("converted_amount")
        .assertTextContains("92")
}

Testing with different configurations

@Test
fun rtlLayoutMirrorsCorrectly() {
    val context = InstrumentationRegistry.getInstrumentation()
        .targetContext
    val rtlContext = ContextWrapper.wrap(context, Locale("ar"))

    composeTestRule.setContent {
        MaterialTheme {
            ConvertScreen()
        }
    }

    // Verify layout is mirrored
    composeTestRule.onNodeWithTag("currency_selector")
        .assertIsDisplayed()
}

Running instrumented tests

# Start an emulator first, then:
./gradlew connectedAndroidTest

These take longer — 2-10 minutes depending on the number of tests and emulator speed. Run them less frequently than unit tests.

Common instrumented test patterns

Test navigation:

@Test
fun backButton_returnsToPreviousScreen() {
    composeTestRule.onNodeWithTag("settings_icon").performClick()
    composeTestRule.onNodeWithTag("back_button").performClick()
    composeTestRule.onNodeWithTag("amount_input").assertExists()
}

Test list rendering:

@Test
fun favoritesList_showsAllItems() {
    composeTestRule.onNodeWithTag("favorites_section")
        .onChildren()
        .assertCountEquals(5)
}

Test touch interaction:

@Test
fun longPressChart_showsTooltip() {
    composeTestRule.onNodeWithTag("rate_chart")
        .performTouchInput {
            longClick(center)
        }

    composeTestRule.onNodeWithTag("chart_tooltip")
        .assertExists()
}

Layer 3: Lint and type checks

This isn’t testing in the traditional sense, but it catches the same bugs — wrong types, unused variables, deprecated APIs.

# Lint
./gradlew lint

# Type check (if using ktlint or detekt)
./gradlew ktlintCheck

Run these before unit tests. They’re fast and catch obvious issues.

Putting it all together

Here’s the full test workflow in one script:

#!/bin/bash
echo "Running lint..."
./gradlew lint

echo "Running unit tests..."
./gradlew testDebugUnitTest

echo "Running instrumented tests..."
./gradlew connectedAndroidTest

echo "Done!"

Save it as test.sh, make it executable (chmod +x test.sh), and run it before every commit.

Using AI to generate tests

If you’re using OpenCode or another AI coding tool, here’s how to generate tests effectively:

1. Describe the test case in plain language: “Write a test that verifies cross-rate computation when converting from USD to JPY. The database stores EUR→USD = 0.92 and EUR→JPY = 148.50.”

2. Let the AI read your existing tests to match the style: “Match the testing style in ConversionCalculatorTest.kt.”

3. Run the generated test:

   ./gradlew testDebugUnitTest --tests "ConversionCalculatorTest.cross rate from non-EUR source computes correctly"
   

4. If it fails, describe the failure: “The test failed because calculateCrossRate expects a RateEntity not a Double. Update the test to create a RateEntity with the correct fields.”

5. Iterate until green.

This works best for unit tests. For instrumented tests, you’ll need to run them on a device and copy the error output back to the AI.

What to test (and what not to)

Test:

• Business logic (conversion math, search parsing, data filtering)
• Database operations (insert, query, migration)
• API response parsing (JSON → data class)
• UI interactions (button clicks, navigation, text input)

Don’t test:

• Framework code (Room, Retrofit, Compose internals)
• Simple getters/setters
• Configuration (dependency injection setup)
• Code that’s trivially correct

The rule: If a bug in this function would cause a user to see wrong data or crash the app, test it. If the worst case is a minor visual issue, skip it.

Common mistakes

Writing tests that are too coupled to implementation:

// Bad: Tests the implementation, not the behavior
@Test
fun `conversion calls repository then formats result`() {
    verify(repository).getRate("USD", "EUR")
    verify(formatter).format(0.92)
}

// Good: Tests the outcome
@Test
fun `converting USD to EUR returns formatted amount`() {
    val result = viewModel.convert(100.0, "USD", "EUR")
    assertThat(result).isEqualTo("92.00")
}

Not cleaning up test data:

@Before
fun setup() {
    database.clearAllTables() // Clean slate for each test
}

Relying on real network calls:

// Bad: Depends on network
val rate = api.getRate("USD", "EUR")

// Good: Mock the API
whenever(api.getRate("USD", "EUR")).thenReturn(0.92)
val rate = api.getRate("USD", "EUR")

Skipping error cases: Always test what happens when things go wrong. Network timeout. Invalid input. Missing data. These are the bugs users actually hit.

The bottom line

Testing isn’t glamorous. It doesn’t make for exciting demo videos. But it’s the difference between an app that works on your phone and an app that works on everyone’s phone.

Start with unit tests for your business logic. Add instrumented tests for critical UI flows. Run lint before every commit. Use AI to generate test boilerplate, but verify every line yourself.

Your users won’t thank you for tests. But they’ll never see the bugs you caught.

I didn’t write most of the code. Not in the traditional sense, anyway.

What vibe coding means

Andrej Karpathy coined the term “vibe coding” earlier this year. The idea is simple: you describe what you want in plain language, the AI generates the code, and you steer it by giving feedback. You’re not typing characters one by one. You’re directing.

It sounds lazy. It’s not. You still need to understand the architecture, make design decisions, catch bugs, and know when the AI is wrong. But the act of writing boilerplate, wiring up dependencies, and translating designs into Compose — that part is largely automated.

My setup

I use OpenCode, an open source AI coding agent that runs in the terminal. It reads your entire project, understands the context, and generates or modifies code based on what you ask.

Here’s what a typical session looks like:

1. I describe a feature: “Add a home screen widget that shows the current conversion rate with Material You dynamic colors”
2. OpenCode explores the codebase, reads existing files, understands the architecture
3. It proposes changes — new files, modifications to existing ones, XML layouts
4. I review the diff, accept or reject, give feedback
5. It iterates until the feature works

The key difference from a code editor with autocomplete: OpenCode doesn’t just complete the line you’re on. It reads your build.gradle.kts, your existing ViewModels, your database schema, and generates code that fits your project’s patterns. If you use Room for persistence, it generates Room entities. If you use Hilt for DI, it generates Hilt modules. It mimics your existing code style because it can see it.

What I actually do

I don’t describe every function signature. I describe outcomes.

“Build a chart component using Compose Canvas that shows 90 days of exchange rate data with cubic Bézier curves, gradient fills, and touch interaction for crosshair tooltips.”

OpenCode generates the Canvas composable, the gesture detection, the data filtering logic. I run it on the emulator. The curves look wrong? I say “the curves are too jagged, use cubic interpolation.” It fixes it. The gradient doesn’t fade correctly? “The gradient should go from the trend color to transparent.” It adjusts.

Most of my time is spent on three things:

• Architecture decisions — Should the widget compute cross-rates or store them? Should the chart data be cached in Room or recomputed on each render? The AI can suggest, but I decide.
• Testing — I write instrumented tests that verify the UI actually works on a device. OpenCode helps generate test cases, but I run them and interpret failures.
• Edge cases — The AI doesn’t know that Frankfurter API returns rates relative to EUR, or that SQLite migrations need to preserve data. I tell it.

What surprised me

The speed. Not of the AI — of the iteration cycle. When generating code is the bottleneck, removing that bottleneck means features ship in hours instead of days.

The chart feature in Offline Currency Converter — gradient fills, cubic curves, dashed grid lines, touch interaction, date range tabs, rate summary row — that’s maybe 200 lines of Compose Canvas code. It took an afternoon. A year ago, that would have been a week of Stack Overflow searching and library evaluation.

Activity Trace’s search engine — the query parser, the notification listener, the encrypted database, the export functionality — about 1,400 lines across the whole app. Built in a weekend.

What doesn’t work

Vibe coding has limits.

Large refactors are risky. If you need to restructure 15 files, the AI might get confused about which changes depend on which. I do those manually or in small steps.

It hallucinates APIs. The AI might use a Compose function that doesn’t exist yet, or call a Room method with the wrong signature. You need to compile and test frequently. Every few changes, not at the end.

Context window matters. OpenCode reads your whole project, but very large codebases get summarized. If the AI needs to understand a 500-line file in detail, it might miss things. I keep my files small and focused — partly for readability, partly for the AI.

It doesn’t replace understanding. I still read every line of code before committing. I still understand the architecture, the data flow, the edge cases. The AI generates, but I verify. If you skip the verification step, you’ll ship bugs.

The workflow

Here’s my actual workflow for a new feature:

1. Describe the feature in a single sentence or paragraph
2. Let OpenCode explore — it reads existing code, understands patterns
3. Review the proposal — new files, modifications, dependencies
4. Accept and test — run on emulator, check for visual issues
5. Give feedback — “the padding is wrong”, “this should be a different color”, “this crashes on API 26”
6. Iterate until it works
7. Run lint and tests to catch anything the AI missed
8. Commit with a clear message

It’s not magic. It’s a productivity multiplier. If you know what you’re building, it gets you there faster. If you don’t know what you’re building, it’ll generate code that compiles but doesn’t solve your problem.

Try it

If you’re building Android apps and haven’t tried vibe coding, start with a small feature. Not a new app — a single feature in an existing project. Add a settings screen. Build a widget. Implement a chart.

OpenCode is free and open source. Install it, point it at your project, and describe what you want. You might be surprised how far a good description gets you.

Source: github.com/anomalyco/opencode

After launching on F-Droid, the feature requests started coming in. Favorites so you don’t have to search for the same currencies every time. A chart to see how rates have moved. A widget so you don’t even have to open the app.

I built all three. Here’s what changed in v0.4.0.

Favorites and multi-currency view

The most common request was obvious: “I use USD and EUR every day. Why do I have to scroll through 160 currencies every time?”

Now you can star any currency as a favorite. The Convert screen shows your favorites as chips below the input — tap one to convert directly to it, or see all your favorites at once with amounts filled in. No more scrolling.

New installs get a sensible default set: USD, EUR, GBP, JPY, and CNY. You can add or remove favorites in Settings. It’s a small change, but it makes the daily-use experience dramatically better.

Building charts with pure Compose Canvas

I wanted rate trend charts, but I didn’t want to pull in a charting library. The app is 3 MB. A charting library would double that. And the charts I need are simple: a line, some shading, a few grid lines.

So I built it with Compose Canvas. The entire chart is about 200 lines of code.

The line uses cubic Bézier curves instead of straight segments — it looks smooth even when rates barely move day to day. Below the line, a vertical gradient fades from the trend color to transparent. The grid uses dashed lines so they don’t compete with the data. And the whole thing changes color based on whether the rate went up or down over the selected period.

The chart fetches 90 days of data from the Frankfurter API and stores it locally. You can filter to 7, 30, or 90 days with tab buttons — the filtering happens client-side, no extra network requests. The selected range persists across app restarts.

Long-press anywhere on the chart and a crosshair appears with the exact date and rate. It’s the kind of interaction that feels obvious once it’s there, but getting the touch detection right on a Canvas composable took some iteration. The gesture detection has to distinguish between a tap (scroll the page) and a long press (show the tooltip), which means tracking pointer events manually instead of relying on Compose’s built-in combinedClickable.

Below the chart, a summary row shows the current rate, the percentage change, and the high/low for the selected period. It gives you the numbers without making you interpret the curve.

A home screen widget

The widget was the hardest part — not because widgets are complex, but because Material You made it interesting.

On Android 12 and above, the widget uses your system’s dynamic color palette. Pick a blue theme, the widget card is blue. Pick green, it’s green. On older devices, it falls back to a teal that matches the app’s branding.

The widget shows a single line: “1 USD = 0.92 EUR”. That’s it. Minimal, glanceable, useful.

The tricky part is computing the rate. The app stores rates relative to EUR — so to show “1 USD = 148.50 JPY”, the widget has to look up USD→EUR and EUR→JPY, then divide. This cross-rate computation had to be fast (it runs on every widget update) and correct for all 160+ currency pairs.

The widget also updates automatically when you change currencies in the app or after a background sync. No manual refresh needed.

Smarter sync behavior

The old approach synced exchange rates every time you opened the app. It worked, but it was wasteful — if you open the app 20 times a day, that’s 20 API calls to get the same rates.

The new approach syncs only on first install and when the app updates. Between versions, the rates you synced last time are good enough. If you want fresh rates, there’s a manual sync button. Pull-to-refresh always works too.

It’s a small change that saves battery and data, and it fits the app’s philosophy: work offline first, sync when it matters.

Everything else

A few other changes worth mentioning:

• Amount persistence — type “100”, close the app, come back tomorrow. It still says 100. The default is 1 if you haven’t typed anything.
• Copy button — tap to copy the converted amount to your clipboard. Useful when you’re sending a price to someone.
• Sync status badge — a small colored indicator shows how fresh your rates are. Green for recent, yellow for aging, red for stale.
• Settings navigation — Settings is now accessed via a gear icon in the header instead of a bottom nav bar. One less thing on screen.

Try it

If you’ve been using the app, update and let me know what you think. If you haven’t tried it yet, it’s free, open source, and works without internet.

Source: github.com/DavidNeurieder/offline-currency-converter (AGPL-3.0)

I got tired of losing data my phone had already processed. So I built Activity Trace — an on-device search engine that captures notifications, screen content, and file text, then lets you search across everything. No internet, no AI, no cloud.

Why notifications are the worst

Android’s notification history is a band-aid. It stores the last 50 notifications in a flat list with no search. If you dismiss something, it’s gone from the shade. If you reboot, the history is wiped. And it only covers notifications — what about things you saw on screen but didn’t get a notification for? Or text inside a downloaded PDF?

Activity Trace captures three sources:

• Notifications — via NotificationListenerService, every notification is captured as it arrives
• Screen content — via AccessibilityService, text you see on screen (including in-app content, browser pages) is captured
• Files — PDFs and text files in Downloads and Documents are indexed for search

All three feed into a single encrypted database. You search once, get results from everywhere.

Search that works without AI

The search understands natural language queries out of the box:

• yesterday signal — finds everything from Signal yesterday
• last week tracking — finds tracking numbers from the past week
• in:whatsapp july 3 — narrows by app and date
• type:notification confirmation — filters by source type

Under the hood it’s SQLite LIKE substring matching with a query parser that extracts date ranges, app filters, and content type filters. No embeddings, no vector database, no cloud API. The first query returns in ~5ms.

I started with FTS5 (full-text search) but dropped it when I realized the LIKE approach was simpler, had zero maintenance, and performed identically at the scale of personal data (thousands, not millions, of records).

Encrypted by default

The database is encrypted with SQLCipher (AES-256-CBC). The key lives in Android’s hardware-backed Keystore. If the device is locked, the database is unreadable.

The app has no internet permission in the manifest. Not “we promise not to use it” — the app literally cannot make network calls. There’s no telemetry, no crash reporting, no phoning home.

Export, backup, and restore

You own your data. The Settings screen offers:

• Export as CSV — RFC 4180 with UTF-8 BOM, Excel-compatible
• Export as JSON — full structured export
• Backup to SQLite — unencrypted copy of the database
• Restore from backup — imports an SQLite backup, merging with existing data and skipping duplicates

No cloud sync, no proprietary format, no vendor lock-in.

Retention that makes sense

Notifications pile up. Activity Trace automatically cleans up records older than a configurable retention period (7, 30, or 90 days). The cleanup runs via Android WorkManager — it happens in the background, respects Doze mode, and doesn’t impact battery.

The tech stack

• Single-Activity Jetpack Compose with Material 3 and dynamic color
• Room + SQLCipher for the encrypted database
• WorkManager for scheduled retention cleanup and file indexing
• NotificationListenerService + AccessibilityService for capture
• Min SDK 26, targets Android 14 (API 34)
• No Google Play Services — distributed exclusively through F-Droid

The entire UI is about 700 lines of Compose. The capture layer is about 400 lines across three services. The database layer is about 300 lines including migrations.

Building for F-Droid

Releasing on F-Droid meant:

• All dependencies verified FOSS (SQLCipher BSD-3, PDFBox Apache-2.0)
• ProGuard minification with logging stripped in release builds
• R8 deterministic mode for reproducible builds
• No Google Play Services, no proprietary dependencies
• Full fastlane metadata with screenshots and changelogs

The build process is automated with a Python script that runs lint, unit tests, instrumented tests (on an emulator), and both debug and release APK builds.

What’s next

The app is feature-complete for v0.7.0. Future directions I’m considering:

• Widget — a homescreen search bar for instant access
• Clipboard monitoring — capture copied text passively
• Better file indexing — expand beyond Downloads/Documents to other directories via SAF
• Search suggestions — autocomplete from historical queries

Try it

If you’ve ever found yourself scrolling frantically through notifications looking for something you know you saw, give it a try.

Source: github.com/DavidNeurieder/ActivityTrace (GPL-3.0)

I needed to get to my hostel and the taxi drivers outside were quoting prices I couldn’t even process. So I found the local bus stop, hopped on, and paid the conductor 20,000đ.

20,000 Vietnamese Dong.

At the time it felt like a lot. Look at all those zeros! 20,000! In my head I was thinking “that’s like 20 bucks or something.” I sat there on the bus feeling like I’d just spent a fortune on a single ride.

Spoiler: it was incredibly cheap. A 45-minute bus ride across town for less than a euro. I only realized how cheap it was a few days later when I took a similar trip and finally understood the scale of Vietnamese Dong.

That’s Vietnam for you. The currency is Dong (VND), and everything runs on numbers that look like phone bills. A bowl of phở? 50,000đ. A coffee? 20,000đ. A hotel room? 500,000đ. Coming from a country where a coffee costs 3€, I had no internal reference point. I was either overpaying or thinking I overpaid when I actually got a steal.

The Zero Problem

Vietnamese Dong has a simple problem: too many zeros. 1 USD is about 25,000 VND. So every price is multiplied by 25,000 in your head. Quick, what’s 350,000đ in euros?

Stares blankly.

Your brain shuts down after the first calculation. You start guessing. “That looks like a lot of zeros, maybe it’s expensive?” Or worse: “That looks like nothing, let’s buy three.”

I’ve paid 50,000đ for a water bottle (should be 5,000đ) and celebrated finding a “cheap” 150,000đ meal (that’s actually normal).

How I Fixed It

I pulled out my phone, opened Offline Currency Converter, and typed in the number. No internet needed. Tap, done. 20,000đ → 0.80€. That’s a bus ride across the city. 50,000đ → 2€. That’s a bowl of phở.

The app doesn’t need a signal to work. It downloads exchange rates in the background when you’re on WiFi, stores them locally, and works everywhere. On the plane. In the subway. In a Hanoi back alley with zero bars.

After a week, I stopped needing it. Your brain eventually calibrates. “20k is a bus ride,” “50k is lunch,” “500k is dinner.” But that first week? It saved me from feeling ripped off when I actually got a bargain.

The App That Lives on My Phone Now

It’s called Offline Currency Converter and it’s on F-Droid. 3 megabytes. 160+ currencies. Offline-first. No ads. No tracking. No internet permission.

It’s the first thing I install before any trip — right after “check how much a local bus actually costs.”

I’ve been building this for a while, and seeing it on F-Droid with that green badge feels amazing. It’s a privacy-first currency converter that works entirely offline. No ads, no internet permission, no tracking — exactly the kind of app F-Droid was made for.

Getting onto F-Droid was a fun ride with a few bumps along the way. Here’s the story.

How F-Droid Works

F-Droid is brilliant: they build every app from source themselves. You just submit metadata and a git tag. Their servers clone your repo, build the APK, and — if it matches your local build byte-for-byte — it’s published. No APK uploads, no shady binaries.

The steps:

1. Add metadata — A fastlane/metadata/android/ directory with descriptions, screenshots, feature graphic, and changelogs.
2. Create a build recipe — Submit a PR to the fdroiddata repo with a YAML entry pointing to your repo.
3. Get reviewed — The F-Droid maintainers check everything and merge.
4. Build farm does its magic — The app gets built and published.

From PR merge to appearing in the F-Droid client: about 2 days. That’s incredible.

Oops: My Metadata Was Invisible

If you check version 0.1.0 on F-Droid, you’ll see the app icon, feature graphic, and screenshots are all missing. The app works fine, but the store page looks embarrassingly bare.

Why? I put my fastlane/ directory inside app/fastlane/ instead of at the project root. F-Droid’s build system only looks for fastlane/metadata/android/ at the root of the repo. My metadata was invisible!

Easy fix: move fastlane/ to the root. Next build, everything should show up.

The Reproducible Build Headache

F-Droid requires the APK they build to be byte-for-byte identical to yours. It’s a great security practice — if anyone tampered with your source, the hashes wouldn’t match.

My first build attempt failed. Their APK was different from mine. After digging in, the culprit was classes2.dex.

The cause? Baseline profiles. The Android Gradle Plugin includes baseline profile files (baseline.prof, baseline.profm) under /assets/dexopt/. These embed non-deterministic metadata like timestamps, which made classes2.dex differ between builds.

The fix was one line:

// app/build.gradle.kts
packaging {
    resources {
        excludes += "/assets/dexopt/*"
    }
}

One exclusion rule and the problem vanished. What a relief!

More Tips for a Deterministic Build

Here’s the full checklist I ended up with:

• Disable R8/ProGuard — isMinifyEnabled = false. R8 can produce non-deterministic output.
• Strip VCS info — vcsInfo.include = false. Build metadata differs between environments.
• Disable dependency info — dependenciesInfo.includeInApk = false.
• Disable build cache — org.gradle.caching = false in gradle.properties.
• Add .gitattributes — * text=auto eol=lf with *.png binary. Line endings will break reproducibility.
• Use the Gradle wrapper — Pin the exact Gradle version.
• Use apksigner 34 — apksigner 35+ produces non-deterministic signatures. Compare unsigned APKs to be safe.

The moment of truth — build twice and compare:

./gradlew clean assembleRelease
cp app/build/outputs/apk/release/app-release-unsigned.apk /tmp/apk-1.apk
./gradlew clean assembleRelease
cp app/build/outputs/apk/release/app-release-unsigned.apk /tmp/apk-2.apk
sha256sum /tmp/apk-*.apk

When the hashes match… chef’s kiss.

It’s Live!

After fixing the metadata location and the baseline profile issue, the F-Droid maintainers merged my recipe. A couple of days later, the app appeared in the F-Droid client with full metadata, screenshots, and the green badge on my README.

That feeling when you search your own app and it shows up? Unreal.

Get it on F-Droid

Source code on GitHub under AGPL-3.0.

If you’re thinking of publishing your own app on F-Droid — do it. The process is rewarding, the community is amazing, and nothing beats seeing your app on that green badge. Go for it!

I open a currency converter app to figure out how much that taxi should cost, and it gives me a spinning circle. The app needs the internet to work. I’m standing in an airport with no roaming — the one time I actually need a currency converter — and it’s useless.

This happens everywhere: on planes, on trains, in tunnels, in parking garages. Even in hotels with “free WiFi” that requires a browser login that your currency converter can’t use.

The real use cases

I built Offline Currency Converter for specific situations I keep finding myself in:

You just landed. You’ve arrived in a new country, you’re at baggage claim, and you need to know what a fair price is for a ride into the city. You have no SIM yet, the airport WiFi requires a SMS verification you can’t receive, and every converter app is showing a loading spinner. This app opens and works immediately — it already synced rates the last time you had WiFi at home.

You’re on a plane. You’re looking at the duty-free magazine and want to know if that bottle of whisky is actually a deal. No WiFi on this flight (or it costs $30). Open the app, tap two currencies, get your answer. No signal required.

You’re in a subway. You’re commuting underground and need to check a price before you buy. No signal for the next 20 minutes. The app doesn’t care.

You’re traveling somewhere remote. Hiking, camping, road tripping through areas with spotty coverage. You synced rates before you left. They’re still on your phone.

You’re on a budget while traveling. You’re checking prices and want to know exactly what you’re spending in your home currency. You open and close the app dozens of times a day — it should be instant, not waiting for a network request every single time.

How it works for the user

Open the app, and you see two currency fields and a number pad. Pick your currencies, type an amount, and you get the conversion instantly. That’s it.

The app remembers your recent currencies so you don’t have to search for them again. It keeps your last 10 conversions visible as a history list. If rates haven’t been updated recently, you’ll see a small banner at the bottom: “Rates may be outdated.” The conversion still shows — just with a heads-up.

There’s no account to create. No sign-up. No ads. No permissions beyond internet access. It’s a tool, not a platform.

What’s under the hood (briefly)

The app syncs exchange rates from the free Frankfurter API whenever you’re on WiFi or mobile data — automatically, in the background. You can set the sync interval from every 6 hours to once a week. Between syncs, all conversions use the cached rates stored locally on your phone.

If you’ve never had internet since installing (happens more than you’d think — people install apps before trips), the app has hardcoded fallback rates for all 160+ currencies. They’re not as fresh as live rates, but they’re accurate enough to know if that $50 tour is reasonable.

The whole app is 3 MB. Smaller than a single photo. And it supports 14 languages natively — including Arabic right-to-left layout — so if German or Japanese or Hindi is your preferred language, the app speaks it out of the box, no download required.

Where to get it

The app will be published on F-Droid — free, open source, no tracking. You can also grab the APK directly or build from source on GitHub.

Next time you land somewhere new and your phone has no signal, you’ll have one less thing to worry about.