-
-
The full run at a glance: 3.28% cut to 2.49%, $9,454 a year back, and a "1.35 factor" advance exposed at 93% APR.
-
The owner's whole interface is one text thread. She sends a statement photo, gets three lines back, and nothing moves until she replies YES.
-
The Fee Hunter checks all 12 statement lines and explains in plain English which fees she can fight: $1,203.75 a month.
-
Hardball and Diplomat negotiate with a simulated rep. The Referee picks the best first year deal, since switching would leave her $316.
-
The "simple 1.35 factor" translated: $38,800 received, $197.26 taken daily for 274 days, and a true cost of 93.3% APR.
-
12 contract traps across two documents, with $27,969 at risk. Each shows the harmful clause struck out and the language to ask for instead.
-
After her YES: the fee on a $48.20 ticket drops from $1.58 to $1.20, $787.83 sweeps to her reserve , and a lender-ready PDF is ready.
Inspiration
Independent restaurants run on 3–4% margins, and card processing takes 2–3% of every swipe. The processor can end up taking about as much as the owner keeps. Much of that hides in tier surcharges, junk fees and contracts nobody has time to read. Then a cash advance arrives promising "\$40,000 in 24 hours, simple 1.35 factor," and it sounds like 35%.
These owners don't need another dashboard. They need someone to read the fine print and fight for them, without adding another app to their day. So we built ShadowBuyer for Main Street, where the owner's whole interface is one text thread.
What it does
The owner texts a photo of their card statement, and a swarm of AI agents gets to work:
- Statement Reader turns the photo into line items.
- Fee Hunter flags the fees the owner can fight.
- Rate Scout compares their rate with a fair benchmark and competitor quotes.
- Hardball and Diplomat negotiate with a simulated processor rep, side by side.
- Referee explains which deal wins on first-year dollars.
- Contract Exposer finds the true APR of the cash advance and rewrites harmful clauses.
- Action Drafter writes the rep email and a three-line text to the owner.
Nothing happens until the owner replies YES. Then the sandboxed actions run and they get a lender-ready PDF.
In our demo, a fictional restaurant goes from 3.28% to 2.49%, worth \$9,454 a year, and a "1.35 factor" advance turns out to cost about 93% APR.
How we built it
- Backend: Python and FastAPI, with the agents' progress streamed to the UI over server-sent events
- Frontend: React 19, Vite and Motion
- AI: the Anthropic SDK, using Claude Sonnet 5.5, Haiku 5.5 and Opus 5.5 according to each agent's job, with structured outputs, streaming and prompt caching
- Actions: Stripe test mode, Twilio SMS and PDF reports with ReportLab
- Reliability: 112 tests, plus GitHub Actions that build and smoke-test the Docker image
Our main rule is that money math is code, never a model. The effective rate is simple division:
$$\text{effective rate} = \frac{\text{total fees}}{\text{card volume}} = \frac{\$3{,}277.40}{\$100{,}000} \approx 3.28\%$$
The cash advance needs more work, because it's repaid through daily debits. We solve for the daily internal rate of return $$r$$, where $$N$$ is the cash actually received and $$p_t$$ is the debit on day $$t$$:
$$N = \sum_{t=1}^{T} \frac{p_t}{(1+r)^t}, \qquad \text{APR} = 365\,r$$
With \$38,800 received and about \$197.26 debited daily for 274 days, the APR is about 93.3%.
The Referee's choice also comes from the calculators. Switching processors looks best on paper, until exit costs are included:
$$\text{first-year net} = \$10{,}773.36 - \$11{,}089.70 = -\$316.34$$
Challenges we ran into
- Keeping models away from the money. Offers come from a fixed ladder priced by our calculators. If the verdict, email or redlines quote a number the calculators didn't produce, the answer is rejected.
- Passing tests didn't mean a working app. While 45 tests were passing, running the app exposed a path traversal bug, forgeable approvals, and "yes please" being read as a decline. We fixed each one and added regression tests.
- Mock mode hid live bugs. The first real run showed the rep using roughly 500–670 tokens for about 45 words, because thinking counts against
max_tokens. Our old 500-token cap would have cut most of its turns short. - A model that wouldn't overclaim. We told Hardball to say it had "settled at 2.49%" last time. Claude refused because it couldn't verify that, and its explanation leaked into the negotiation. Our prompt was the problem, since the owner might have declined that deal. Now it says what the records actually show: the processor already offered 2.49%.
What we learned
- Let models read, argue and explain, and let tested code do the math.
- Approvals should fail safe. A reply like "what does this mean?" isn't a yes or a no, so we ask again and nothing moves.
- Fallbacks make a demo reliable, but they can also hide bugs, so test with real keys early.
- Clear labels build trust. The app shows what's live and what's mock.
What's real and what isn't
- Real: a full run on the Claude API, with all 8 AI agents live and no fallbacks, in about 80 seconds for about \$0.17. All figures come from our calculators.
- Simulated or fictional: the processor rep, restaurant, lender and documents. Nobody real is contacted. Benchmarks and quotes are illustrative.
- Sandboxed: Stripe and Twilio, which haven't been tested against the real services yet. No real money moves.
- Prior work: this builds on our earlier ShadowBuyer procurement project, kept in
legacy/. The negotiator idea, stylesheet and UI layout carried over; the product, agents and money math are new.PRIOR_WORK.mdhas the details.
Log in or sign up for Devpost to join the conversation.