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
Pricing
- 月 50 件まで取引可
- カテゴリ 3 つ
- カード 1 枚
- 基本 AI OCR
- 取引無制限
- カテゴリ・カード無制限
- 優先 AI OCR
- デュアル領収書アーカイブ
- 実質 NT$83 / 月
- 専門版すべての機能
- 高度なエクスポート







