RemitPal — Project Story

Inspiration

Hundreds of thousands of Indonesians work abroad, and many of them are wives. Siti works in Hong Kong while her husband Slamet stays home in Indramayu, caring for the land and the children. Every month she sends money home: Rp 15,000,000 for renovation, tuition, living costs, and savings, and every month she has to trust, blind, that it was spent on the family.

Too often it wasn't. The money went to expensive things instead of the things that build a family's future, and in some cases she only found out later it went somewhere else entirely. And she can't just ask. In our culture, a wife asking her husband "where did the money go?" is itself inappropriate. It sounds like distrust, and it starts a fight. So nobody asks, and nobody knows, until it's too late.

RemitPal exists so the app asks for her. She sends, he spends, and both of them can see where every rupiah went, without her ever having to ask.

What it does

RemitPal is a family remittance ledger for Indonesian migrant workers, especially the wives.

Siti tells the AI agent, in natural language, what the month's money is for. The agent turns it into a structured plan: renovation Rp 5,000,000, tuition Rp 3,500,000, living Rp 4,000,000, savings Rp 2,500,000, and shows her an approval card. Only when she clicks Approve does the money move, via PayPal Payouts (sandbox), from her own account to Slamet's verified email, in a day or less instead of the usual 2–4 days.

Then Slamet spends locally and reports every expense with a receipt photo. The AI reads the photo, extracts the vendor, amount, and item, categorizes the expense, and logs it as pending, never verified. Siti reviews it and confirms it. The AI audits; the family decides.

How we built it

  • Frontend: React 19 + Vite + Tailwind, seven screens: Overview, Expenses, Remittances, Receipt Vault, Budget Plan, Transfer & Task Schedule, Audit Statement, plus a chat-first AI assistant on every screen.
  • Backend: Express + TypeScript, PostgreSQL, with auth on every data route and role-gated tools (Slamet cannot set budgets or verify his own receipts; only Siti can).
  • AI: server-side Gemini 3.8 Flash, with an OpenRouter fallback (nvidia/nemotron-3.5-super-vl:free) and a labelled rule-based fallback when no key is present. The agent can structure plans, review receipts, categorize expenses from photos, and schedule reminders, but it has no PayPal tool, cannot send money, cannot delete or edit expenses, and cannot mark a receipt verified.
  • PayPal: Payouts v1 (sandbox). The USD amount is computed server-side from the approved rupiah total (Rp 15,000,000 → $937.50 at a labelled display rate of Rp 16,000/USD); the model's own amount is overridden if it doesn't match. A record is created only when PayPal reports SUCCESS, with the real payout ID.
  • Deploy: a Render Blueprint (render.yaml) provisions the database and web service, with a one-click Deploy to Render button so a judge can host their own replica.

Challenges we ran into

The biggest one was the payment method. We first built the send step on PayPal Personal Payments v2, the natural fit for a person-to-person transfer — and the credentialed sandbox run failed with 403 NOT_AUTHORIZED. Personal Payments is a limited-release API that needs a separate approval; the Payouts approval we already had did not carry over, and it isn't listed among the hackathon's payment capabilities at all. Payouts is. So we reverted to Payouts, and reframed the product honestly: RemitPal is Siti's personal app, so the payout comes from her own sandbox business account, only after her in-app approval.

The AI layer fought back too. Gemini was frequently overloaded, so we added the OpenRouter Nemotron fallback, which turned out to handle receipt photos and expense categorization well, and kept the rule-based fallback labelled, never faked.

And a local test caught a bug a judge would have spotted on screen: "Total Transferred to Date" read Rp 1,794,481,580,320 against nine Rp 15,000,000 transfers. One row had a millisecond timestamp written into its amount field. We added a 500M IDR amount cap and a guard against timestamp-shaped amounts, and deleted the bad row.

What we learned

The technical lesson is that the guardrails are the product. An AI that can move money or declare a receipt verified is not helpful, it's dangerous. Every boundary in RemitPal (human approval before payment, AI-verified downgraded to pending, role-gated tools, server-computed amounts) exists because a family ledger has to be trustworthy to both people reading it.

The human lesson is the one that started it: transparency is not surveillance. Siti doesn't want to monitor her husband. She wants to stop having to wonder. A shared ledger, asked for by a neutral system instead of a spouse, gives her that without a fight.

What's next

After the hackathon: a multi-user version, where Personal Payments v2 is the right method so each sender pays from their own personal account; a proper mobile experience for Slamet in the field; and opening the code under the open-source umbrella, so other migrant families can run their own copy.

Built With

Share this project:

Updates

Submission history