Rateio helps agricultural cooperatives organize a purchase before it becomes a pile of messages, receipts, and duplicate orders. It combines a Rails API, a React Native admin app, a WhatsApp channel for suppliers, supplier-sheet parsing, and receipt verification that tries OCR before falling back to an LLM when a read is unclear.

Problem

Buying seeds, fertilizer, or equipment together can unlock better prices, but the coordination often happens in WhatsApp. Receipts disappear into chats, more than one person buys the same item, and no one has a reliable record of who has paid. The hard problem was not splitting a transaction; it was giving a group one shared view of the purchase and its evidence.

Research changed the product boundary

The initial direction was embedded split payments. Interviews showed that the group already knew how to pay with Pix; the missing layer was management: which purchase is open, who has joined, who has paid, and what proof exists. That changed the implementation target from a payment gateway to a coordination and audit system around the payment method people already used.

Mechanism

The product's permission model is the control point:

1. Members can suggest a collective purchase.
2. An administrator decides when there is enough demand and publishes one canonical split.
3. The system notifies interested members, records their payment evidence, and keeps the purchase visible to the whole group.

That restriction is deliberate. Letting anyone publish a split would recreate the fragmented-chat problem inside the app: several near-identical purchases, each too small to achieve collective pricing.

WhatsApp as an operational interface

The bot gives members a low-friction way to join the organization, receive a new-purchase alert, and open the menu for products, their cart, or previous purchases without installing another app.

Engineering work

• A Rails API designed for incremental adoption. The React Native admin app currently runs on Firebase in production; the Rails API is the path for moving responsibility over without a big-bang rewrite.
• Operational channels, not just screens. A WhatsApp bot communicates with suppliers, while supplier spreadsheets are parsed into product data the group can act on.
• Receipt verification with a bounded fallback. OCR handles clear receipts; when extraction is uncertain, an LLM fallback helps recover the fields that need review instead of silently treating a poor scan as truth.
• A reproducible local environment. Docker brings up the services so a contributor does not need Ruby, Node, Expo, or Postgres installed directly just to run the project.

What I would extend

The next valuable step is making the evidence trail easier to audit at a glance: show each payment's source, extraction confidence, reviewer decision, and the state transition that changed the purchase. The system already gathers the ingredients; the remaining work is turning them into an explanation a cooperative can trust during a dispute.