Inspiration
Small service teams (tailors, designers, caterers, cleaners) are usually paid as one lump sum, and then the argument starts: who worked how long, who did the harder part, who gets what? The boss ends up doing messy mental math, and someone always feels short-changed. We wanted to make fair pay the default and make it fast, exact, and paid out in one step.
What it does
BudPay helps an agency share one customer payment fairly with its crew.
- A customer books a service and pays through PayPal Orders.
- The boss describes who did what in plain words.
- Gemini reads the story and extracts each person, their task, and their hours.
- BudPay calculates an exact split, the boss reviews it and approves, and one PayPal Payouts batch sends everyone their share.
The key design rule: the AI understands, but never moves money. Gemini only turns text into structured suggestions. The boss confirms them, and the server does the math.
How we built it
- Frontend: Next.js (React) deployed on Vercel
- Backend: Node.js / Express API
- Auth and data: Supabase (email and Google sign-in, workspace-scoped roles)
- Payments: PayPal Orders for checkout, PayPal Payouts for crew disbursement, with live status tracking
- AI: Gemini for story parsing, with a deterministic fallback parser so the app keeps working if the model is unavailable
The crew pool is what remains after costs and the boss's share:
$$P = \text{payment} - \text{costs} - \text{boss share}$$
Each person's weight comes from their hours and skill level, and their share is proportional to it:
$$w_i = h_i \cdot s_i, \qquad \text{share}_i = P \cdot \frac{w_i}{\sum_j w_j}$$
For example, from a \$200 payment with \$40 in costs and a \$90 boss share, the \$70 pool splits into \$35.00, \$29.17 and \$5.83, which add up to exactly \$70.00.
Challenges we ran into
- Rounding money: floating-point math drifts by a cent. We do all calculations in whole cents on the server, so the shares always sum exactly to the pool.
- Duplicate payouts: a double click must never pay people twice. Payout batches are idempotent and claimed atomically.
- Trusting AI output: model output is a suggestion, never an instruction. Everything is validated, and the boss approves before any money moves.
- Honest payment status: PayPal payouts take time to process, so a person is shown as Paid only after PayPal confirms their payout.
- Email and auth setup: getting reliable confirmation and password-reset emails working with Supabase and SMTP took real debugging.
What we learned
- Where AI belongs in a payments product: on understanding, not on authority.
- Building around asynchronous payment states instead of assuming instant success.
- Treating money as integers from the start saves a lot of pain.
What's next
- Connected agency payments: the routing for paying each agency's own PayPal merchant account is built, and we're waiting on PayPal platform enablement to turn it on.
- Multi-currency payments.
Built With
- express.js
- gemini
- next.js
- paypal
- smtp
- supabase
