Missing cashback isn’t a tracking problem. It’s a trust problem.
Over half of CashKaro’s negative reviews trace back to one loop: the order doesn’t track, the user raises a ticket, waits 8–10 days, and often gets a cancellation with no reason. TrackBack is my PRD and working MVP for closing that loop.
Users experience eight different failures as one: “they didn’t pay me.”
Click windows, app-to-app handoffs, last-click attribution to coupon sites, items already in the cart, outside coupons, one-item-per-cart stores, validation lags, reason-less rejections. Most “missing” cashback is the rules working as designed. But the product never says which rule, so every case becomes a ticket and a suspicion. The fix is to decide instantly where the rules already decide, explain everything else, and give a person only the cases that need judgment.
Three surfaces, one engine
“It didn’t track” → answered in seconds
Share a screenshot, email or SMS. An LLM reads it, the rules engine checks it against the visit log, and the user gets: filed for you, wait (we’ll re-check), add one thing, or no, with the exact rule.
Pending and cancelled, explained
Every rupee shows which step it’s at, what the store is waiting for, and what happens next. Moved dates come with a reason. Cancellations come with one plain sentence and an appeal if one can work.
Agents only see what needs judgment
High-value and risky claims arrive with evidence and a drafted reply. Overrides are logged to tune rules. Reason codes roll up into the product fixes that would stop claims happening.
Measured, not asserted
Review analysis, a 1,000-claim simulation, an impact model you can edit, a 400-scenario test suite with zero false auto-files, and parser vs LLM extraction scores.
AI reads. Rules decide. AI words, inside a guardrail.
Screenshots, forwarded emails, SMS and Hinglish chat become structured order fields. Every field is sanity-checked and confirmed by the user.
Eligibility and cashback amount are deterministic: auditable, testable, explainable to a store and to a regulator. No model decides money.
Messages can be rewritten warmly in English or Hinglish. A guardrail rejects any rewrite that adds a number, date or amount the engine didn't produce.
Why this split: an LLM is far better than regex at messy input (the rule parser breaks on Hinglish and SMS), but a wrong cashback decision costs money and trust, and has to be explainable to the store’s affiliate team. When the API is down, the parser takes over and the product still works.
PRD in the morning, prototype by lunch, MVP by evening.
Built with Claude Code as the co-builder: I set the problem, the principles and the decision spec; I reviewed and tested what it produced. Where it was wrong (a regex that matched “Order Confirmation” as an order ID, a test that assumed the wrong cashback rate), review and the tests caught it before it shipped.
Next.js · TypeScript · Tailwind · LLMs via Groq (gpt-oss-120b, Qwen vision) and the Claude API · Vitest · Python for research
- 01ProblemScraped 6,000 Play Store reviews, coded 633 complaints into themes (Python, reproducible).
- 02PRDRoot causes, RICE prioritisation, decision spec, metrics, experiment and a 30-day validation plan.
- 03EngineDeterministic rules engine + status explainer in TypeScript, unit-tested boundary by boundary.
- 04AI layerLLM extraction for screenshots, SMS and Hinglish (gpt-oss-120b + Qwen vision on Groq, Claude supported), validated against a schema; guarded rewrite that can't invent numbers.
- 05ProductNext.js app: claim flow, wallet, ops console, impact page. Fallbacks when the API is off.
- 06EvalPlanted-scenario suite, edge cases, extraction scoring, impact stream: one command, same numbers every run.
First 30 days: backtest, shadow, ship the explainer.
Week 1: run the engine on 3 months of real tickets and network outcomes, and talk to 10 users and 5 agents. Weeks 2–3: shadow mode next to agents. Week 4: wallet explainer + auto re-check to 10%. Then the auto-file pilot on Amazon, gated on the rejection-rate guardrail.