WORK / RYBO
RYBO
Run Your Business Operation - billing, stock, dues, deliveries and team for wholesale distributors, on Android and the web. Formerly MyLedger, and running a real distributor's business every day.
ROLE
Product & systems design, built with Claude Code as an engineering partner
STACK
Flutter · Riverpod · Firebase (Firestore, Cloud Functions) · Razorpay · S3
TIMELINE
2026 - ongoing · v1.3.7
STATUS
Live - Gate of India Food
INSIDE THE PRODUCT
THE PROBLEM
Every wholesale business I looked at runs on a paper notebook - stock, dues, and per-buyer pricing tracked by hand. Goods go out with a delivery boy, every buyer has their own rate, and every unpaid rupee has to be remembered and chased. The owner can't see profit in real time, and staff mistakes stay invisible until a reconciliation goes wrong.
RYBO replaces the notebook. One bill saves the sale, moves the stock, records the money, starts the delivery and updates the customer's due - at once, on every phone and PC in the shop.
CONSTRAINTS
- -Real, non-technical end users - every screen has to work without training
- -Several staff billing at the same time on one shared company account
- -Patchy connectivity on the shop floor - billing can't stop when the signal drops
- -Real money: a double tap or a retry must never count a payment twice
- -Old app versions stay installed in the field, so backend changes have to roll out in steps
ARCHITECTURE
Flutter clients (Android and web) read live from Firestore, but every write that moves money, stock or plan usage goes through Cloud Functions - one Firestore transaction per call, carrying an ID made on the device. Triggers keep running totals, so screens read stored figures instead of adding up history.
- 01Flutter + Riverpod - one codebase for the Android app and the web app
- 02Cloud Functions (asia-south1) - createBill, recordPayment, addStock, deliveries, plans; each one transaction
- 03Idempotent writes - device-made request IDs, so a retry, double tap or offline replay lands exactly once
- 04Offline queue - bills made without signal wait on the device and sync themselves; nothing is silently lost
- 05Stored aggregates - triggers maintain customer dues, daily stats and bill counters, so reads stay flat as data grows
- 06Security rules - per-company isolation and Owner / Admin / Staff roles; purchase cost lives in a private ledger staff can't read
- 07Razorpay - checkout in the app, pricing and verification on the server
DECISIONS
1.Moving money writes from the client to the server
The first version wrote straight to Firestore, with security rules doing the access control - it cut out a whole backend and got the product in front of a real distributor fast. Once several people billed at once over patchy connections, that stopped being enough. Now the server is the authority for bills, payments, stock and plan limits, and the rules refuse direct money writes once old app versions are retired.
2.Average cost over FIFO
Real wholesale stock doesn't arrive in clean batches - a true FIFO model needs lot tracking most buyers don't do by hand either. A running average cost is close enough to reality and dramatically simpler to compute and explain to a non-technical owner.
3.Read stored totals, not history
Dashboard figures and customer dues come from aggregates kept up to date by triggers, so the customer list is one small live read whether the business has fifty bills or fifty thousand.
4.Built with Claude Code as an engineering partner
I specified the data model, the server's transaction boundaries, the security rules and the UX; Claude Code handled a large share of implementation. The judgment call was knowing what to specify precisely - schema, access rules, pricing logic - and what to delegate. Not outsourcing the thinking, just the typing.
RESULTS
2,000+
Bills processed
4+ mo
Live with a real distributor
2
Platforms - Android and web
what I'd do differently…
I'd make the server the authority for money from day one. Starting with client-side writes was the right call for speed, but moving off them with old app versions still installed meant a staged rollout - feature switches and a minimum-build gate - that a server-first design would never have needed.
quick answers
Quick answers about RYBO
- What is RYBO?
- Run Your Business Operation - billing, stock, dues, deliveries and team for wholesale distributors, on Android and the web. Formerly MyLedger, and running a real distributor's business every day.
- What is RYBO built with?
- RYBO is built with Flutter, Riverpod, Firebase (Firestore, Cloud Functions), Razorpay, S3.
- What was SK Rohan Parveag's role on RYBO?
- Product & systems design, built with Claude Code as an engineering partner.
- What is the current status of RYBO?
- Live - Gate of India Food. Links: rybo.rohanparveag.in (https://rybo.rohanparveag.in) and Web app (https://app.rybo.rohanparveag.in).