Thelivry

Overview

Package delivery apps aren't new. What's consistent across most of them is who's actually doing the delivering, a rider hired, managed, and priced by a corporation or an agency behind the app. Thelivry starts from a different premise: the person best placed to run your errand might just be someone already headed that way, and they should be able to say so, name their price, and keep the difference.

The challenge

A few problems came up in shaping this.

• Delivery owned by the platform, not the people: existing apps route every delivery through an agency's fleet. A regular person with a bike and some spare time has no way to pick up a delivery and get paid directly.
• One price set by nobody in the conversation: a fixed platform rate doesn't know that a rider is already riding past the pickup address, or that a sender needs it there in ten minutes and would pay more to make that happen. Neither side gets to say so.
• Trust between two strangers and a package: a sender is handing goods, and money, to someone they've never met. A rider is trusting they'll actually get paid once the package leaves their hands. Both sides need protection that doesn't rely on just believing each other.
• Delivery isn't always a package: sometimes what's needed isn't a box moving from A to B, it's a task, a shopping run, an errand, something delegated rather than shipped.

Research & insights

• Name-your-fare ride-hailing (inDrive): the core mechanic, offer a price, let the other side accept or counter, comes from ride-hailing platforms that replaced fixed fares with negotiation. Applying that to package delivery rather than passenger transport is the twist.
• Escrow-based freelance marketplaces (Upwork, Fiverr): holding payment until a job is confirmed complete, rather than paying a rider upfront, mirrors how freelance platforms protect both a client and a contractor who've never met.
• Food and grocery delivery apps (Uber Eats, Bolt Food): the live tracking pattern, a status stepper moving through enroute, picked up, in transit, delivered, alongside a map and a call button, is a borrowed convention from a category people already trust.

The solution

1. One home screen for two ways to get something moved

Package Delivery and Book Errand sit as the two entry points from day one, with ongoing deliveries and history tracked on the same screen so a sender never has to hunt for a previous order.

2. One account for two roles, verified only when it matters

Everyone signs up as a sender first, the app only needs basic information to get started. Becoming a delivery partner or errand runner is a toggle in the profile, not a separate app or a separate application process. But flipping that toggle for the first time changes what the platform asks for: ID documents, proof of address, transportation type, operation area and availability, and a guarantor. The vetting only shows up the moment someone takes on the responsibility of carrying someone else's package and cash, not before.

The guarantor isn't just a name on a form. They receive their own consent request, told plainly who listed them and what they're agreeing to, that they may be contacted if the delivery partner's obligations go unresolved, and they have to actively consent before submitting their own ID and a selfie. A provider can't vouch for themselves by naming someone who never finds out.

3. Book it the way you need it

A sender chooses instant or scheduled delivery, adds recipient details, and describes the package, item, quantity, dimensions, estimated weight, with an optional photo to prove ownership and tags for fragile or perishable handling. Multiple packages can go into one order before it's confirmed.

4. Room to negotiate instead of just accepting

Available riders show up with their rating, delivery count, and a price. A sender can accept it outright or counter with their own offer, the rider can counter back. A short countdown keeps the back-and-forth from stalling into an open-ended negotiation. If either side declines or closes an offer instead of countering, the sender isn't left stuck, they're prompted to search again and dropped back into the pool of available riders rather than hitting a dead end.

5. Payment held until delivery is confirmed

Payment goes into a time-limited escrow account rather than straight to the rider, so a sender's money isn't released, and a rider's promised fee isn't at risk, until the delivery is actually confirmed.

6. Trust built along the route

Real-time tracking shows a status stepper, enroute, picked up, in transit, delivered, next to a live map and a direct line to the rider, not a support bot. In-app chat keeps that same human tone, casual, a little jokey, closer to texting someone you know than filing a support ticket, which matters when the whole premise is a stranger carrying your package. A four-digit handover code, shared only at the point of delivery, gives the recipient a way to confirm receipt without paperwork or a signature.

7. Close the loop

Once delivered, the sender rates the experience and leaves optional feedback, closing an order the same way it opened, in one screen, without a second app or a follow-up email.

Two products in one shell

Package delivery and errand booking share almost the entire flow: entry point, negotiation, escrow, tracking, closeout. The errand side carries its own shopping-specific steps, choosing one or more stops, listing items to buy, confirming the actual cost against what was quoted, and reviewing the runner's purchase receipt, but rides on the same underlying core as package delivery rather than becoming a second product to maintain.

Learnings

• Negotiation needs a clock: without a countdown, back-and-forth over price could stretch indefinitely while a package sits waiting. A short timer on each counter-offer keeps bargaining from becoming a stalling tactic.
• Escrow acts as the trust layer, not a footnote: when two strangers are exchanging cargo and cash with no prior relationship, the payment mechanism carries as much weight as the tracking screen. It needed the same design attention, not less.
• A handover code is cheap insurance: one four-digit code, shared only at the final step, settles "I never received it" disputes without requiring ID checks or signatures neither side wants to deal with mid-delivery.
• Vetting should arrive exactly when it's needed: asking every sender for ID and a guarantor upfront would kill signups before anyone sends a single package. Asking for it only when someone volunteers to carry other people's cargo, right at the moment the risk profile actually changes, keeps the barrier where the risk is instead of at the front door.
• A vouch only counts if the voucher knows about it: naming a guarantor is easy to fake if the guarantor never finds out. Routing consent, and the actual accountability language, directly to that person closes the obvious hole, a provider can't list someone who hasn't agreed to carry that risk.
• Two products in one shell: package delivery and errand booking share almost the entire flow, entry point, negotiation, escrow, tracking, closeout. Building one flexible core kept the two from becoming two separate products to maintain.