2026 · Product · Architecture · Ops
GetHelp Reimagined
Send help to anyone, anywhere — with money that only moves when the help actually happens.
Half the world has someone they can't reach. The other half would help a stranger for $20. GetHelp connects them — with escrow and milestones so neither side has to trust the other on faith.
§01 — Case study
The shape of the work.
If you've ever lost contact with someone you love in a place you can't reach, you already know why this exists. GetHelp lets you send a stranger to check on them — and only pays out when they actually do.
Receipts — current traction
Two people. One need. Total strangers.
Someone, somewhere, needs a small thing done — a wellness check, a document delivered, a meeting witnessed, a parcel collected. Someone else, nearby, would do it gladly for a fair price. The internet connected them years ago. Nobody made it safe to actually transact.
A brother, an address, and silence.
A friend's family in Nigeria lost contact with their brother in the US. They had his address. They had no one nearby. By the time they found out he'd been arrested, days had passed. If GetHelp existed, they'd have paid a verified Helper $20 to knock on the door, send a photo, confirm he was okay. That's the product. Everything else is plumbing.
“If you can't reach the person you love, you should be able to send a stranger who can.”
Trust has to be in the database, not in the vibes.
When the task is emotional, escrow can't be a marketing word. I put dual-sig funding, milestone immutability, and refund eligibility into Postgres triggers and RLS — not React. Every milestone the Helper completes unlocks the next slice of money. Both parties sign, or nothing moves. The client can't game it because the database is the contract.
A planet-scale safety net, priced like a coffee.
Helpers earn real money doing small things in their own city. Askers get peace of mind for the price of a takeout meal. And the architecture — the trust, the escrow, the milestone math — is the moat. Competitors copy the UI in a weekend. They don't copy this in a quarter.
§01.5 — From the product
§02 — Story
Inception → Outcome
01 · Inception
A family that couldn't reach their brother
Someone we knew in Nigeria had a brother who traveled to the US. The family lost contact. No relatives there, just an address. He had been arrested — and no one knew for days. If they could have paid a stranger $20 to knock on a door, the story ends differently.
02 · Discovery
Two sides of the same need
There are people who need a small thing done somewhere they can't reach — check on someone, deliver a document, witness a meeting. And there are people, everywhere, who'd happily do it for a fair price. The market existed. The trust didn't.
03 · Decisions
Trust has to live in the contract
Reviews and support tickets aren't enough when the task is 'go check if my brother is okay.' I put every trust rule — dual-sig funding, milestone-locked amounts, refund eligibility — into Postgres triggers and RLS. The client can't lie because the database won't let it.
04 · Build
Milestones, cancel, refund
Helpers report milestones. Money releases as each one is verified. Cancel before funding, refund after (Asker-only, traceable). Funds never get stuck — and neither does anyone waiting on the other side of the world.
05 · Ship
Realtime, end-to-end
Notifications, deep links, live contract state. Both sides see the same truth, instantly. The kind of clarity that makes someone in Lagos comfortable sending money to a stranger in Atlanta.
06 · Outcome
A safety net you can pay for
Not a marketplace for tasks. A way to get help to a person, anywhere on the planet, with money as the trust mechanic.
§03 — Outcomes
post an address, a task, a person to check on — get a verified Helper nearby
money releases only as the help actually happens
both sides sign or no money moves — refund button always works
Next