Project Arbi™
Self-initiated, no client
My role Product design and engineering, solo
Thesis, conversation design, system, build
When March – April 2026
Team One person
Platform Web · Next.js 14 + React, NestJS on Fastify
PostgreSQL · Prisma · OpenAI · Stripe Connect
Status Live at arbi.now

My Role

Arbi is a self-initiated product, design and engineering by me, end to end. Two people who disagree about something small are interviewed separately by an AI investigator, and the system returns a written decision. No accounts, no download, one shared link. If they want, they can put money on it.

It is a deliberately awkward product to design, because the interesting parts are the ones a demo hides. A verdict is easy to generate and hard to make trustworthy. The work was in the parts that decide whether anyone believes the answer: how the questioning behaves, what the system is allowed to say when it does not know, and what happens to real money when a decision lands.

  • Product Direction: Defined the thesis, an investigator that gathers facts from both sides in private, not a chatbot that referees an argument in a shared thread.
  • Conversation Design: Wrote the rulebook the AI follows, tone, question style, follow-up logic, and the root causes it is looking for, then encoded its hard limits in the backend rather than the prompt.
  • UX & Interaction Design: Designed the full flow across two strangers and two devices: claim, invite, private interview, clarification round, decision, payout.
  • Design System: Built a token-based component set on a near-black canvas, one type scale, one motion vocabulary, shared across every screen.
  • Engineering: Built both halves, a NestJS/Fastify API with a Prisma relational model, a Next.js client, Stripe Connect escrow and payouts, web push, and the scheduled jobs behind every deadline.

The Product

One person starts a case and gets a link. The other person opens it. Neither sees what the other wrote. Arbi interviews each of them separately, then compares the two accounts, asks a clarifying question if it needs one, and issues a written decision with its reasoning attached.

The whole thing is built to be finished in one sitting. A case lives for 24 hours and then expires; the second party has a response deadline; push reminders fire on a fixed ladder as both clocks run down. Nobody creates an account at any point, and the entire product ships in three languages.

Entry, the case screen both parties share, and the landing state once real cases exist.

Design Challenges

An AI that settles arguments is trivial to prototype and very easy to get wrong. Ask a model to judge a dispute and it will always produce something confident, fluent and shaped like a verdict, whether or not it has the facts. The design problem was never generating a decision. It was building the conditions under which a decision deserves to be believed.

  • Two Strangers, Two Devices: Most conversational products design for one person in one session. This one has two people who may be hours apart, must not see each other's answers, and are not going to sign up for anything. The case screen became the shared object, with each party holding a PIN instead of an account.
  • Judge vs. Investigator: A judge persona invites performance, people write for the verdict instead of describing what happened. Reframing Arbi as an investigator that only decides after both interviews are done changed the tone of every question in the product.
  • Interrogation Fatigue: Enough questions to be fair, few enough that a phone-typing user finishes. The interview is bounded to three minimum, five target, seven maximum, with follow-ups only when an answer is genuinely unclear.
  • Confident Nonsense: The failure mode of an AI judge is a well-written verdict with nothing under it. Decisions carry a confidence value, an evidence weight and the factors behind both, and one of the valid outcomes is that there is not enough here to decide.
  • Money Changes the Stakes: The moment a case has a pot, every soft edge in the flow becomes a hard one: who is the winner of record, who may claim, what happens if nobody does, and what happens if a payment succeeds at Stripe and the process dies a second later.

The Rulebook

Before writing the interview I wrote the rules it has to obey, as a document, in plain language. Tone, question length, what a follow-up may reference, what it may never reveal, and the root causes the investigation is trying to surface: misunderstanding, miscommunication, broken expectations, unmet agreements, timing.

The five core questions are deliberately short enough to answer while walking:

  • What happened?
  • What led up to it?
  • How did this affect you?
  • Did you try to resolve it?
  • What would feel fair to you?

The important part is where those rules live. Anything the product cannot survive being wrong about is enforced in the backend, not requested in the prompt. The model is told the minimum interview length; the API also refuses a submission below it, and forces another question if the model tries to end early. A returned decision that is not one of the known categories is normalised, and anything unrecognised falls back to insufficient information rather than to a guess. Prompts are instructions. Invariants are code.

Putting Something On It

Free arbitration is easy to walk away from. The stake exists because a decision nobody is bound by is just an opinion, and the smallest honest form of commitment between friends is not a contract, it is who is buying.

Both parties pay in, the pot is held in escrow, and the winner claims it through Stripe Connect. A platform fee comes out of the pool. There is exactly one appeal per case, and it only runs if both sides accept it, so an appeal is a mutual second look rather than a losing party's retry button. An unclaimed pot expires on a timer instead of sitting in limbo forever.

Shown in test mode, where the stakes are set to $0.50 and $1.00.

The Interface

The canvas is near-black with a single soft aurora behind everything, and the mascot is the only saturated object on screen. That is doing real work: the subject matter is already tense, and a bright interface reads as a courtroom. The owl is what makes a stranger willing to type the true version of what happened.

Everything else is deliberately quiet. One idea per screen, one primary action, generous line length for reading a decision, and a footer that says in plain words that this is not legal advice. The same component set carries the phone and the desktop layout, because a case routinely starts on one and finishes on the other.

The Decision

The product promises a verdict. The decision that shaped everything else was to let it decline to give one.

The path I took

The system may refuse to pick a winner

Alongside finding for either party and finding shared responsibility, insufficient information is a first-class outcome, with the confidence value and evidence weight that produced it shown rather than hidden. It is also the fallback: anything the model returns that cannot be recognised resolves to a refusal, never to a coin flip.

The option I killed

Always name a winner

Force a side every time, with a percentage split for close cases. It is what the product appears to promise, it is what people opened it to get, and it makes the paid flow trivial, because there is always someone to pay.

What choosing it cost

A user can pay, wait, and be told nobody won, which is the single worst moment in the product and one I built on purpose. It forced a whole second system to exist: an escrow that can unwind, a pot with no winner of record, a claim window, and a defined end state for money nobody collects. A percentage split would have removed all of it. What I could not defend was an arbitrator that is never allowed to say the honest thing, because a judge who always rules is not neutral, just decisive, and once money is on the table that difference is the entire product.

How I Knew It Held

There are no usage numbers here and I am not going to invent any. What I can show is where I chose to spend the effort, which was on the two places this product can actually hurt someone: the money and the claim to neutrality.

Payout safety suite
Four adversarial scenarios, run against the live backend
What it actually tries to break
Two simultaneous claims on one pot; a crash after Stripe has already succeeded, reconciled from the webhook; every claim state that must refuse a second payout; and repeated transitions proving the whole thing is idempotent.
Invariants in code, not prompt
Minimum interview length is enforced by the API, an early exit is overridden with another question, and an unrecognised verdict category degrades to a refusal instead of a guess.
Stated confidence
Every decision carries a confidence value, an evidence weight and the factors behind them, so a weak call is legible as a weak call.
Nobody is left waiting
Scheduled jobs drive a fixed reminder ladder against both clocks, 45 and 15 minutes on the response deadline, 12, 3 and 1 hours on case expiry, each fired once and recorded.
Identity without accounts
Each party holds a bcrypt-hashed PIN. Claiming a payout re-verifies it, and clarification cannot be reached by guessing a URL.

What was never measured

Everything that matters most. I have no data on whether people accept a verdict they lose, which is the only success metric this product really has. Nor on completion rate for the second party, the drop-off point inside the interview, how often the system refuses to decide on real disputes rather than my test cases, or whether the stated confidence predicts acceptance at all. Those are four instrumentation jobs and one study, and none of them can be answered from my own machine.

What I would do differently

I designed the neutrality and then validated the plumbing. The payout path has been attacked from four directions; the verdicts have been read by one person, who is also the person who wrote the rulebook they follow, and who knew what the right answer was before reading them. That is the weakest possible ground truth for a product whose whole claim is impartiality.

The honest next step is not the appeal flow or a fifth language. It is running twenty real disputes past a handful of people who have no stake in my being right, and finding out whether the losing side accepts the decision, because a verdict nobody accepts is a text generator with an owl on it.

Conclusion

Impact: Arbi takes the least serious thing in the world, an argument about who owes who a coffee, and treats it with the seriousness the mechanism actually needs: a written rulebook, an interviewer that is not allowed to overreach, a decision that can decline itself, and real money moving under transactional guarantees. Roughly 19,000 lines across a hundred-odd files, designed and built solo in a month. It is the clearest example of how I work on AI-driven products, which is to assume the model will eventually say something wrong and design the system so that when it does, nothing important breaks.