Building a Multi-Currency App: The Edge Cases Nobody Warns You About

Wed, 22 Oct 2025 09:00:00 +0000

When I started building Famorize, I thought multi-currency support would be a weekend feature. “Just store the currency code and multiply by the exchange rate, right?”

Wrong.

Dealing with money in software is a masterclass in edge cases, data integrity, and precision. If you’re building an app that handles more than one currency, especially one designed for families across borders, the complexity stacks up fast.

Here are the four big lessons I learned from building Famorize’s multi-currency engine.

1. Never, Ever Use Floating Point Numbers

This is the “Day 1” rule for financial software, yet I still see it in production. Floating point numbers (like double or float in most languages) are inherently imprecise for decimals. $0.1 + 0.2$ in IEEE 754 floating point is not $0.3$; it’s $0.30000000000000004$.

In Famorize, everything is stored as integers in the smallest unit (e.g., cents for USD, yen for JPY, satoshis for BTC). If a transaction is $10.50, it is stored as 1050. This eliminates rounding errors at the database and application levels.

2. Exchange Rate “Drift” and Historic Validity

Exchange rates are not static. If a user recorded a $50 CAD transaction today, it might be worth $37 USD. If they look at that same transaction next year, it should still be $50 CAD. But what was its USD value at the time?

To handle this, Famorize doesn’t just store the transaction. It stores:

The Base Amount (in the user’s home currency).
The Original Amount (in the transaction currency).
The Exchange Rate Used (at the time of the transaction).

This “Snapshot Pattern” ensures that reports are accurate to the moment the money actually moved, not the current market rate.

3. The “Yen Problem” (Zero-Decimal Currencies)

Most developers assume a currency always has two decimal places. This is a trap.

While USD, CAD, and EUR have two (cents), currencies like JPY (Japanese Yen) have zero, and others like BHD (Bahraini Dinar) have three. If your UI or database assumes integer / 100 is the decimal value, you will break for users in Japan or Bahrain.

Famorize uses a Currency Metadata table that defines the “Scale” (decimal places) for every supported currency. The display layer is responsible for formatting based on this scale.

4. The UX of “Which Currency?”

If a user in Toronto is sending money to a family member in Nairobi, which currency should the input field show?

The UX pattern that worked best for me was to always let the user select the Transaction Currency while showing a real-time “estimated conversion” into their Home Currency. That gives them a clearer sense of how much they are spending in the units they understand.

The Result

Building a multi-currency app taught me that “precision” is not just a technical requirement; it is a trust requirement. If a financial app is off by even one cent, the user’s trust is broken.

Famorize now handles dozens of currencies with an integer-based engine that I can trust with real family finances. It took more than a weekend, but the lessons were worth the effort.

Related reading:

OAuth2 and OIDC for Solo Developers: A Practical Setup With Docker

Mon, 15 Sep 2025 09:00:00 +0000

Authentication is the classic “black hole” of side projects. You start with a simple idea, and four days later you’re still reading RFC 6749 and wondering if you should just use a password in a plain text file (don’t).

For my personal projects like Famorize and FireFly, I needed something standards-compliant and easy to manage across multiple services. It also had to be dependable. I didn’t want to pay $50/month for a managed identity provider (IdP) for projects that were still in development, but I also didn’t want to roll my own crypto.

The solution was a self-hosted OIDC setup using Docker.

Why OIDC?

If you’re building a “modern” app, you’re likely using a decoupled architecture: a frontend (React/Next.js/Hugo) and one or more backend APIs. You need a way to:

Log a user in.
Prove to the API that the user is who they say they are.
Do it securely without sharing passwords everywhere.

OpenID Connect (OIDC) is the standard way to do this. It sits on top of OAuth2 and provides the “identity” layer.

The Stack

For my local and production environments, I settled on a “trio” of tools that play very well together in Docker Compose.

Authelia: A lightweight, self-hosted IdP. It’s fast, has a great UI, and supports multi-factor authentication (MFA) out of the box.
Redis: For session storage and rate-limiting.
Nginx Proxy Manager (or Traefik): To handle the routing and SSL termination.

The “Local First” Workflow

The biggest pain point with OIDC is setting it up locally. Most managed services require a public redirect URI, which is a nightmare for localhost development.

With a self-hosted setup, I can use a local domain (like auth.local.chingono.com) and point it to my Docker container. This means my local development environment is identical to production. If it works on my machine, the OIDC flow will work in the cloud.

Key Lessons Learned

Building this into my projects taught me a few hard-won lessons:

Scopes and Claims are everything. Spend the time to understand the difference. Don’t just request openid profile email and hope for the best. Define only what your app actually needs.
HTTPS is non-negotiable. Even for local development, OIDC requires secure cookies. Use mkcert to generate local SSL certificates and save yourself the headache of “Insecure Connection” errors.
Token rotation matters. If you’re building a long-lived app (like a mobile client for Famorize), you need to handle refresh tokens correctly. Don’t just set a 30-day expiration on your access tokens.

Why Not Just Use Auth0 or Clerk?

Managed services are great for teams with a budget and no time. But as a solo developer who enjoys the “Build in Public” ethos, I find that owning my identity layer is worth the extra effort. It gives me complete control over the user experience, total data sovereignty, and a much deeper understanding of the security architecture.

If you’re interested in the specific Docker Compose configurations I use, stay tuned for the next post in this “Craft” series.