Fair Shift

The right people. The right place. The right time. The right pay. FairShift uses AI to turn unpredictable staffing demand into equitable, transparent earning opportunities.

Comment

Inspiration

Somewhere in Johannesburg this afternoon a manager is scrolling a group chat at four o'clock, looking for someone who can be on the floor by five. Somebody will say yes. They'll pay for the taxi, work the shift, and go home without knowing exactly what they earned or when it will arrive.

FairShift starts in South Africa. Two days before this deadline, Stats SA published the latest jobs figures: 33.7% of the labour force is unemployed, and 47.3% of people aged 15 to 34. When work is that scarce, the person asking for a shift is in no position to ask questions about it.

Restaurants, cafés and bars run on those shifts, yet most venues still plan them by gut feel. When demand is guessed, both sides lose. The owner is short-staffed on the busy night and overstaffed on the quiet one. The worker is called in late, sent home early and paid days later, with card tips held until month-end.

FairShift grew out of one sentence: casual work shouldn't mean casual pay.

It has a limit, and we'd rather say so. Software won't make an exploitative employer fair. It can make fairness the easy path for the many owners who want it, and it can put the terms in front of the worker before they say yes.

What it does

FairShift plans, fills and pays casual shifts in one place. The AI notices and checks, people decide, and PayPal pays.

sales history → forecast → staffing gap → suggested shifts → fair offers → confirmed work → Pay Agent check → PayPal payout → Paid ✓

Plan. A forecast by time of day from each venue's own sales history, comparing Saturdays with Saturdays. Local signals adjust it: events, closures and weather that the AI finds, each with a source page that FairShift fetches and checks itself. A source it can't confirm is shown but never applied. Nothing changes staffing until an owner or manager accepts it.

Fill. Suggested shifts arrive cut to the venue's rules. Every offer carries the pay terms and a minimum-wage check, so nobody is offered a shift below the legal floor. Offers go first to workers who have said they want more hours, then to everyone eligible.

Work. Workers use a phone app. They see each offer with its full terms before accepting, and those terms are fixed once they accept. They follow their shifts, inbox and pay in the same place.

Pay. A manager confirms the hours. The Pay Agent checks the shift. If every check passes and the hours were confirmed within 24 hours of the shift ending, FairShift sends the payout through PayPal Payouts straight away. Otherwise the payment is held, and only the owner can release it, with a written reason. The worker sees rand first: 6 h × R45.00 = R270.00. The payout goes in US dollars at the European Central Bank reference rate, locked when the payout is created. Paid shows only when PayPal reports SUCCESS.

Tips. Card tips follow each venue's written rule, per shift block, and are checked by the Pay Agent before release. A casual worker's share is paid as its own PayPal payout, after the shift, not at month-end.

The quiet feature. When a casual worker's hours pass a threshold the owner sets, FairShift alerts the owner to consider a permanent role. It never makes the offer itself. It makes regular hours visible to the person who can.

Records. Every PayPal call and AI call is listed with its identifiers and can be downloaded as CSV.

Workers see only their own earnings. There are no leaderboards, and workers are never charged.

How PayPal is used

PayPal is the money layer for both sides of the product, all in the PayPal Sandbox.

  • Payouts API pays workers for confirmed shifts and tips. Each payable has a deterministic sender_batch_id, so a retry can never pay twice. An unknown or timed-out result goes to reconciliation, never to Paid.
  • Subscriptions API bills venues: a 30-day free trial, then a monthly or annual plan (R499 or R1,149 a month including VAT, billed as US$30.17 or US$69.48).
  • Webhook signature verification means subscription and payment events are trusted only when PayPal signs them.
  • OAuth 2.0 client credentials for server-to-server access.
  • Each business pays its staff from its own PayPal Sandbox app, connected in Business settings. The secret is stored encrypted and only its last 4 characters are shown. FairShift never falls back to a shared account for payouts, and the records show which account sent each one. Subscriptions are billed through FairShift's own PayPal app.
  • Negative tests were run against the Sandbox with Postman and Newman: 13 of 15 matched the expected result, and 2 were recorded as PayPal returned them.

How AI is used

AI suggests and checks. It never sets an amount, picks a worker or books a shift. Every pay, forecast and staffing figure is computed by deterministic code.

  • Local signals. A web search per location for events, closures and weather that could change demand. FairShift fetches each cited source itself.
  • Staffing briefing. A short explanation of which gaps to fill first, citing FairShift's own figures. Drafts in which the model writes its own figures are rejected.
  • Pay Agent. Checks each confirmed shift for hours beyond the booking, overlapping work, timing and duplicate records. When every check passes it releases the payment at the amount FairShift computed. Otherwise it holds the payment for the owner.

How we built it

Next.js (App Router, server actions) and React in TypeScript. PostgreSQL with Drizzle and SQL migrations. PayPal REST. The OpenAI Responses API. Resend for email, Bryntum Scheduler for the schedule view, Open-Meteo weather, Nager.Date public holidays and the ECB reference rate. Hosted on Render. More than 1,300 automated tests run against an in-process PostgreSQL.

FairShift is a new project. The first commit is dated 14 October 2026, inside the submission period.

Challenges we ran into

Rand can't travel through PayPal Payouts. A worker who earns in rand wants to see rand. So each payout converts once at a locked reference rate and never re-converts on a retry.

A payout can time out after PayPal has accepted it. The engine reserves the payout before calling PayPal and treats every uncertain result as "reconcile", not "resend". Nobody is paid twice, and nobody is told they were paid when they weren't.

A language model will happily invent a number. FairShift validates every AI draft against its own figures and discards the ones that fail.

What we learned

The hardest state in a payment is "we don't know". Treating unknown as unknown, not as failed or paid, shaped most of the payment code.

AI was the only thing that was capable for noticing and checking, and least trustworthy for deciding. I learnt AI might know it all, but it also required me to know what I was doing. Which I didnt

Fairness turned out to be mostly a matter of order: terms before acceptance, the wage check before the offer, confirmation before pay.

What's next

Rand payout rails, automatic cancellation pay, and more point-of-sale sources for sales and tips.

Everything so far runs in the PayPal Sandbox with a fictional demo business. The step that matters is a real Friday, and a real person who knows what they earned before they get home.

Built With

Share this project:

Updates

Submission history