Okaro

The problem

Standard bookkeeping apps assume one currency. But proxy buyers deal with two numbers per transaction: the foreign-currency price at point-of-sale and the local-currency amount the credit card actually charged. I spent a while inside the proxy-buying community, and the real pain wasn't math — it was the cell-soup of yen, NTD card charges, and prorated shipping crammed into a single Excel column. One typo nuked the margin on the entire batch.

What I built

A dual-currency precision system. Two columns by design: the foreign-currency total at swipe time and the local-currency total the card billed. Snap a Japanese receipt — the AI parses merchant, date, amount, and currency in one shot. The architecture is credit-card-first: every transaction starts from a card, because the proxy-buying scene runs on card rewards.

Technical decisions

• SwiftUI 而非 UIKit：Solo dev, declarative UI lets me iterate fast. Drop down to UIKit only where I need surgical control.
• App Store over pure web:The audience lives in iPhone + credit-card apps. Native unlocks fast receipt capture, currency widgets, and FX-rate push.
• Freemium NT$99/月、NT$999/年：NT$99/mo is the sweet spot I landed on after surveying Taiwan subscription apps; NT$999/yr is "10 months, get 2 free" — an anchor users already understand without being taught.

What I learned

What I learned: the narrower the niche, the easier it is to keep users. I'll never beat a generic bookkeeping app — but in proxy-buying I can be the best.

Numbers

5.0★
App Store TW
v1.1.2
9 versions in y1
3 langs
繁中 · EN · 日本語

Pricing