A student photographs a receipt; the university's finance office gets the exact PDF memo it requires. Refund cycles went from three weeks to days, and five tools became one.
The problem
Before this app: a student WhatsApps a photo of a receipt. The finance officer copies the supplier into Excel, adds a row to a Monday board, and at the end of the month re-types everything into a PDF memo template — the tzkir — that the university requires in an exact format. Refunds took three weeks on a good month. Students stopped bothering with small amounts. The club ate the cost.
The tzkir header: the university-mandated PDF the whole product is designed backwards from
The app
Open it. Photograph the receipt. Gemini reads supplier, amount, and date and fills the form; you confirm the category and which budget it hits, and submit. Ten seconds, from a parking lot, in Hebrew. Submissions land in one admin queue — bulk approval for everything clean, flags on outliers, and editing allowed in exactly one place so nothing drifts.
Student flow: photograph a receipt and Gemini auto-fills supplier, amount, and date
The month closes in one click
On the 30th, the admin hits 'generate tzkir'. The system pulls every approved submission, fills the university template, attaches the original receipts, and signs. Fourteen seconds, one file. The finance office receives the same artifact it always did — the work upstream just disappeared.
One-click monthly tzkir generation with live PDF preview
What I did
Product, design, and the full build — designed backwards from one constraint: every month, produce that exact PDF cleanly and on time. Beyond shipping, I built it to be inherited: full Hebrew RTL down to keyboard shortcuts, and a repo documented for a next maintainer who has never seen React — status-flow diagram, an architecture TL;DR in Hebrew, comments only where the why isn't obvious.
Admin review queue with bulk approval and flagged outliers — the only place editing is allowed
Decisions AI couldn't make
The artifact is the spec
The product isn't 'a refund app' — it's a machine that produces one university-mandated PDF. Designing everything backwards from the tzkir is what kept the scope honest and the tool adoptable by the finance office.
Students edit only what the model can get wrong
Gemini fills the form; the student can override supplier, amount, and date — nothing else. Fewer fields means fewer mistakes and a ten-second flow, but deciding where trust ends and confirmation begins was a product call, not a technical one.
One queue, one place to edit
Every edit happens in the admin queue and nowhere else. It costs some flexibility, and it's the reason the data never drifts and a non-technical maintainer can reason about the system.
What I got wrong
I treated the student flow as the product and polished it first. The real user turned out to be the finance officer — the admin queue is where trust is won or lost, and it earned its shape only after real submissions started arriving.
Built with Claude Code + Next.js/Supabase/Gemini; every product decision was mine.
TeachBack
A voice-first AI learning partner — you explain out loud, Lumi asks what you can't answer yet.