monia

One module does all arithmetic on amounts. An amount is a bigint in the minor units of its own currency, and the scale comes from a currencies.decimals column rather than a hardcoded constant: pesos are configured at two decimals here because Bancolombia reports centavos on tax and interest lines. No JavaScript number ever touches an amount, not to parse it, not to convert it, not to format it. Rounding is half away from zero, so a debit and a credit of the same size round to the same size. Asymmetric rounding would bias expenses against income.

There is a catch-up pass for new mail, which is small and runs daily, and a backfill walk that goes backwards through history, is large, and takes days. Every serverless route has a duration cap, so a server-side loop that runs past that cap dies mid-flight and reports nothing at all. Instead each request is bounded and lands its own work: it writes its rows and moves the history floor before it returns. A run that dies, whether from a closed tab or a deploy, loses at most the chunk in flight. The browser loop reads 800 messages a chunk; the cron reads 80.

Two tables carry the import state. One holds a row per message the importer has looked at, with the outcome it reached and the evidence it had. The other holds one row per user with the oldest day read so far. When a user adds an account or a template, the app deletes the seen-rows the change unblocks, so the next import reads them again. Without that step, mail that was one account away from landing stays marked seen forever. The trap: a user with no backfill row has never walked backwards at all, which is the same state as an unfinished walk, and it belongs to the newest account, the one the job exists for. The query that picks up that user needs a LEFT JOIN.

reporting_currency existed as a column, appeared on the settings screen, and was read by nothing. Every page hardcoded the storage base, so a Colombian user with 7,749 peso rows could only ever see dollars. The fix is a SQL expression with three cases, in order of cheapness. If the reporting currency equals the storage base, return the frozen column untouched, so today's numbers equal yesterday's by construction. If the row is already in the reporting currency, return its native amount, because a round trip through USD loses a centavo per row for nothing. Otherwise divide by the rate for that row's own date, never today's rate. A verification script then walked the rows that actually needed converting, comparing them one at a time: zero mismatches across all 184 of them.

Every row's USD base amount is written once at insert and never recomputed, so historical totals are stable by construction, and so the base currency can never change without invalidating every stored row. The per-user reporting currency costs nothing to change, because nothing is stored in it.

Ask a language model how much you spent on food in March and it produces a confident, plausible, wrong figure. In a ledger a plausible wrong figure is worse than no answer, because the user cannot tell it from a right one. So the application computes every figure first, with the same typed queries the screens use, and hands the model a fact sheet; the model says which figures answer the question and writes the sentence around them. I rejected three designs in writing first. Raw SQL for the model is one malformed query from a wrong total and one DELETE from worse. Query tools are better, but the model still picks the window and the filter, so it still owns the number. Retrieval over transaction text answers "did I pay X" well and "how much" badly.

I would rather ship a narrower feature that is always right.

Signing in with Google asks for identity only. gmail.readonly is requested separately, from Settings, and only by the accounts that import mail. The reason is regulatory rather than ergonomic: it is a Google restricted scope, and attaching it to sign-in puts the whole application under the restricted-scope regime. Publishing the consent screen then requires an annual third-party CASA Tier 2 assessment, and until that passes Google expires every refresh token after seven days, which breaks the daily import cron. The cost is one extra consent step, paid only by the users who need it.

A serverless loop that runs past the duration cap dies mid-flight and reports nothing, so no request is allowed to depend on the next one. Each writes its rows and moves the history floor before it returns, and a dropped connection loses at most one chunk. The trade is chunked progress and more requests, and on this platform the long run was never on offer.

When a row has no exchange rate the conversion returns NULL, and sum() skips it without a word. The app counts those rows and shows the count beside the total. The alternative is a clean-looking number over incomplete data, which is the kind of bug a user never files.