Back to Index
Go / Backend
2026·Local implementation complete · CI verified

Catat Uang

Offline-first Flutter finance app with a Go synchronization API

GoPostgreSQLDart / FlutterSQLitenet/httppgxOpenAPIGitHub Actions
Catat Uang Android demo showing the local transaction ledger with sample data
Catat Uang Android demo showing a sample recurring household internet bill
Catat Uang Android demo showing the first-transaction guide
GitHub Repository
↳ Offline SQLite + explicit sync + encrypted backups + backend and Android CI

See the app in use

Two-minute recording from the Android emulator with fictional sample data and no audio. It shows offline transactions, bills, backup settings, reopening the app, and first-entry guidance. This offline demo build does not demonstrate cloud synchronization, physical-device acceptance, or a production release.

  • Sample transactions and recurring bills in the real Flutter interface.
  • Offline entry and data retained after closing and reopening the app.
  • Backup settings and guidance for starting with an empty ledger.

Download video ↗Capture evidence ↗

Catat Uang Android demo showing the local transaction ledger with sample data
Transactions and period summary
Catat Uang Android demo showing a sample recurring household internet bill
Recurring bills
Catat Uang Android demo showing the first-transaction guide
First-entry guidance

My contribution

Implemented the Flutter/SQLite app, Go/PostgreSQL API, explicit synchronization protocols, account recovery, encrypted backups, operational commands and automated backend/mobile verification.

Engineering decisions

  • Keep local finance usable without an account; require explicit linking before uploading records.
  • Persist synchronization queues and use idempotency keys, version checks and conflict review so interrupted requests can be retried safely.
  • Protect bill payments with database transactions, row locks and uniqueness constraints.
  • Verify backups and restore on isolated copies; provide cleanup previews before changing retained server data.

Testing & evidence

  • The project verification report dated 27 October 2026 records successful Backend and Mobile CI for code 57f956c, including Go race/PostgreSQL, vulnerability checks, container checks and native Android emulator jobs.
  • Integration tests exercise two real SQLite ledgers against the Go API, including retry, conflict, payment, reopen and dataset recovery flows.
  • An SMTP loopback test covers HTTP recovery requests, outbox delivery, MIME codes, one-time reset and session revocation.
  • Source code, the verification report and release gates are available in the public repository. The recorded development APK and CI results do not constitute a public production release.

Current limitations & next steps

Public hosting/HTTPS, provider email delivery, production signing and store release remain pending. Real Android device checks, two-device acceptance and iOS builds still require the corresponding hardware/services. Emulator and CI results do not establish production reliability.

Project overview

The problem it solves

An offline-first personal finance application built with Flutter and SQLite, backed by a Go/PostgreSQL API. Optional accounts support explicitly linked, manual synchronization of transactions, recurring bills and payment history through persistent outboxes, idempotent retries and conflict review. Includes encrypted file backups, session management, email verification and password recovery. Local implementation and CI verification are complete; public release remains pending.

SpecificationBackend race / PostgreSQL CI
SpecificationAndroid emulator integration CI
SpecificationSQLite ↔ Go integration tests

How it works

SQLite remains the mobile ledger. Users explicitly link local data to an account before manual synchronization through the Go API; account login alone does not upload financial records.

Main flow
  1. 01

    Flutter → SQLite ledger and persistent sync outbox

  2. 02

    Explicit account linking → manual transaction / bill synchronization

  3. 03

    Go net/http → account isolation, version checks and idempotent operations

  4. 04

    pgx → PostgreSQL transactions, row locks and payment history

  5. 05

    Encrypted email outbox → SMTP worker; encrypted file backup → atomic local restore

Key components
Offline ledger and synchronization

Persistent SQLite queues, safe retries, version conflicts and dataset recovery for transactions, bills and payments.

Account security and recovery

Argon2id password hashing, revocable sessions, password changes, email verification and single-use password recovery through an SMTP outbox.

Atomic financial operations

Database transactions, row locks, unique constraints and idempotency keys protect payment consistency during retries and concurrency.

Backup and operations

Encrypted mobile backups with atomic restore; server backup integrity/age checks, isolated restore verification, health checks and cleanup previews.

Next Project

ReLoop

Circular-Commerce Platform & Escrow Architecture

Explore Next Case