Injiza — making invisible businesses visible

Injiza (Kinyarwanda: "income / what comes in") is AI-powered bookkeeping that works over plain USSD — on any phone, with no internet.

Inspiration

Over 80% of Rwandans work in the informal economy — street vendors, tailors, moto drivers, small shopkeepers. Most of these micro-businesses keep no records at all. The owner can't tell real profit from daily cash churn, can't see which products lose money, and can't get a loan because there is nothing to show a lender. The business is invisible — even to the person running it.

Almost every "fintech for the informal sector" idea assumes a smartphone and a data plan. But the people who most need bookkeeping are the least likely to have either. We kept coming back to one question: what if the only thing you needed was the phone you already own?

That reframed everything. The answer wasn't a slick app — it was USSD, the *384#-style menus that work on a $15 feature phone with no internet and no data cost. It's the same rail mobile money already rides, so it's trusted and understood. Injiza meets the underserved majority exactly where they are.

What it does

A vendor dials a USSD code and types what they bought and sold in everyday language — Kinyarwanda, English, or a mix:

naguze ibirayi 5000, nagurishije 7000

Injiza's AI engine parses that messy, code-switched entry into structured bookkeeping data, calculates profit, and replies with one short, actionable insight. Over time it builds the income history that finally makes a vendor loan-ready — the record a SACCO or microlender needs and that today simply doesn't exist for these businesses.

The same engine also powers a polished smartphone web app for users who have moved up — one brain, two front doors.

How we built it

The core insight is one engine, two skins:

  • The engine is a single call to Claude (Anthropic's API). It takes a free-text entry and returns structured JSON:

    {
    "items": [{ "name": "ibirayi", "cost": 5000, "revenue": 7000 }],
    "total_cost": 5000,
    "total_revenue": 7000,
    "profit": 2000,
    "insight": "Good margin on potatoes today — keep it up!"
    }
    

    Turning "I bought some potatoes and sold most of them" into clean accounting is exactly what an LLM is good at and a spreadsheet is bad at.

  • Skin A — USSD, the headline channel. A lightweight Node / Express webhook receives the request from Africa's Talking, passes the user's text to the Claude engine, and returns a CON / END USSD response. We exposed the local server publicly with ngrok and tested end-to-end on the Africa's Talking sandbox simulator.

  • Skin B — smartphone app, built with React + Vite + TypeScript, styled in a deep azul theme and animated with anime.js — profit numbers that count up, springing message bubbles, and an animated loan-readiness ring.

The profit math is simple and transparent:

$$\text{profit} = \sum_{i}\left(\text{revenue}_i - \text{cost}_i\right)$$

and our illustrative loan-readiness score rewards consistent record-keeping:

$$\text{score} = \min!\left(100,\; 12 \cdot n_{\text{entries}} + 25 \cdot \mathbb{1}[\text{profit} > 0]\right)$$

What we learned

  • The channel is the product. The hardest and most valuable design decision wasn't the AI — it was choosing USSD over an app. It forced a discipline that made the whole thing better: if it has to fit in a tiny text menu, every word has to earn its place.
  • LLMs shine on messy, human input. Code-switched Kinyarwanda/English entries that would break any rules-based parser are exactly where a language model thrives. The win was in the prompt, not the plumbing.
  • Telecom infrastructure is its own world. Webhooks, public tunnels, session formats, and the gap between a sandbox and a live shortcode taught us how much sits between "it works on my laptop" and "it works on a phone in a village."

Challenges we ran into

  • Reaching feature phones for real. Live USSD requires a telecom agreement and deposits we couldn't arrange in a hackathon, so we built and demoed on the Africa's Talking sandbox simulator — a genuine end-to-end flow, just driven through their simulator rather than a paid live code.
  • Getting reliable JSON from a language model. We had to prompt firmly for JSON-only output and defensively strip stray markdown fences before parsing, so a single odd response never crashed the flow.
  • Fitting rich coaching into a USSD-sized reply. USSD responses are short and sessions are brief, which meant ruthlessly trimming the AI's insight to the few words that matter most.
  • Keeping the key safe. Wiring the demo quickly while making sure the API key lived only in environment variables and never shipped to the client.

What's next for Injiza

Move from the sandbox to a live shared USSD code with a telecom partner, add a real weekly-summary SMS, and pilot the loan-readiness history with a local SACCO — so an invisible business can finally walk into a lender with a record of what it earns.

Share this project:

Updates