Dibs

Inspiration

Paying for results is broken in both directions.

A small shop pays a promoter and gets a screenshot of a view count. A game maker pays testers and gets "yeah, I played it". A freelancer does the work and then waits for a client who never presses "approve".

It always comes down to two things: someone has to be trusted, and someone has to press a button. Dibs removes both.

PayPal already has the two pieces this needs. It can hold money without taking it, and it can pay a person by email. What was missing was something in the middle that looks at what really happened and decides, with nobody's thumb on the scale.

What it does

Dibs is a job board where you post a result, not a task.

A business types what it wants in one sentence. AI turns it into a job card: the finish line, how it will be checked, the cheat tests, the pay rule, a "Does not count" list, and how strong the proof is.
The business approves once, in PayPal's own window. PayPal holds the whole budget. The money has not left them, and the job shows the date PayPal's hold ends.
Anyone calls dibs, does the work, and hands in a recording, a photo, a file or links.
A checker built for that job measures what really happened, from the source: a recording AI looks at, a web page Dibs opens itself, clicks on a link Dibs owns, a video's own view count, or PayPal's own record of a sale. A worker's word is never the proof.
PayPal pays exactly what was earned. Dibs takes that part from the hold and sends it to the worker's PayPal, with PayPal's reference on screen.
When the job ends, the rest of the hold is let go. It never left the business.

Nobody presses approve. A result that passes is paid. A result that fails shows why, in one plain sentence.

Any job that can be checked can be posted:

Bug hunt. A game maker lists the bugs it already knows and pays $5 for each new one. The worker uploads a screen recording. The checker finds each bug with the moment it happens and sorts it: new, already known (it names the line it matched), or already paid to someone else. Only new bugs are paid, once.
Something that should be true on the web. A café wants to be listed correctly on three sites. The worker hands in links only. Dibs opens each page itself and compares it with the café's facts. One wrong digit in a phone number is refused, with both numbers shown.
A test with steps. AI marks the moment each rule is met in the recording. Three of four rules means three quarters of the pay.
A sale. A buyer comes through the worker's link and pays with PayPal. The order carries the worker's code, so PayPal itself is the proof. A refunded sale earns nothing.
Promotion. AI checks the video names the brand and says it is paid. Plain code reads the views and counts the clicks.

Cheating is part of the design. One visitor clicking a link 5,000 times counts once. A known bug earns nothing. A job no machine can measure says so on its card before a cent is locked.

Every business also gets a Ledger: every lock, payment and release with PayPal's own reference, in charts and one table.

Try it (no sign-up, no password)

Open https://dibs-eqcw.onrender.com. Everything is PayPal sandbox: no real money moves. The businesses, workers and game are made up.

Tap the name at the bottom of the side menu and pick a business (Loom & Thread) or a worker. One tap switches you.
As a business: Post a job, type any result in one sentence, and press Write the job card. Then look at People and Ledger.
As a worker: open any job and press Call dibs.
To see a cheat caught: open "Get our launch video 10,000 views".
The demo shop: https://dibs-eqcw.onrender.com/shop

How we built it

PayPal is the spine, not the pay button. All in sandbox:

Orders v2 with intent AUTHORIZE locks the budget as a hold, approved through the PayPal JS SDK v6 button in PayPal's own window. The hold's end date is read from PayPal and shown on the job.
Capturing part of an authorization (with final_capture: false) pays exactly what a result earned, again and again from the same hold.
Payouts sends it to the worker by email, with a note saying what it was for.
Voiding the authorization returns the rest when the job ends.
Sales and refunds: a shop order carries the worker's code in custom_id. Every sale is read again from PayPal before commission is paid, so a refund made anywhere is seen.
Webhooks with PayPal's signature checked, and PayPal-Request-Id on every money call so a retry never pays twice.

Proof, run against PayPal sandbox with the output kept in the repo: $50 held, $4.00 then $8.40 taken from the same hold, the remaining $37.60 released. A later run passed 14 of 14 checks: the hold's end date, full and part refunds, a refund made on PayPal's side, commission paid only for the 2 sales that counted, and the money trail.

AI does only what needs understanding or looking. Claude (claude-opus-5-5) writes the job card from one sentence and judges hand-ins: an uploaded recording is cut into one picture per second and Claude looks at them; it also looks at photos and PDFs and reads web pages Dibs fetched itself. Gemini watches public videos for promotion jobs and answers questions in the Ledger. Each decision comes back as one plain sentence. Every number (clicks, repeats, sales, pay) is worked out by ordinary code. AI never calls PayPal.

Render runs it all from one file: the always-on site, the Postgres database, a disk for uploaded recordings, and a timer that runs the checks every minute.

AG Grid's AG Studio builds the Ledger: the charts and the table of every money move.

Built with Claude Code in TypeScript, Next.js, React and Drizzle.

Challenges we ran into

PayPal would not split a hold the first way we tried. We held $100, took $15, and tried to release the rest: "previously captured". The fix was marking each take as not the final one. That one finding is what makes "pay exactly what was earned" possible.
A hold lasts 29 days, but PayPal only promises the money for the first 3. So a job runs 3 weeks at most and shows its end date.
A refund can happen behind our back. So every sale is read again from PayPal before commission is paid.
Claude cannot play a video. So a recording is cut into one picture per second, and each hand-in is looked at once and the answer kept.
Opening a link a stranger gives you is dangerous. Dibs checks the address at the moment it connects, on every hop, and refuses anything that is not public.
Views are the weakest proof there is. So every job card says how strong its proof is.

Accomplishments that we're proud of

One hold, paid out in exact parts, with the rest released, tested against PayPal, not drawn on a slide.
A refunded sale earns nothing, even when the refund was made on PayPal's side and we were never told.
5,000 clicks from one machine at one link: all stored, one counted.
A checker written from one sentence that refuses a known bug by name and pays two new ones.
A judge can be a business or a worker in one tap.

What we learned

Holding money and paying money are different PayPal features, and the interesting products live in the gap between them.
The strongest proof of a result is a payment.
Keep AI away from the numbers and the money. Let it read, look and explain; let code count and PayPal pay.

What is not finished (honest list)

Sandbox only. No real money has moved.
No passwords: anyone can act as anyone. Right for judging, wrong for real use.
Log in with PayPal is built but switched off.
The bug hunt and café checks ran with the real AI on a laptop copy, not yet end to end on the live site.
A recording is judged from one picture per second, with no sound, so a split-second glitch can be missed.
A real webhook arriving from PayPal has not been seen yet.

What's next for Dibs

Log in with PayPal switched on, so every worker is confirmed by PayPal.
Real stores connecting their own PayPal, so a sale anywhere can carry a worker's code.
A checker that uses a live website and repeats a reported bug itself.
The 10% fee, then real money, country by country.