Peer-to-peer marketplace for covering delivery routes

Overview

Independent delivery distributors own routes, and sometimes they need someone else to drive them. The platform is a marketplace where a route owner finds a vetted reliever to cover the route: posting the job, hiring, tracking the trip, chatting, and paying out at the end, all in one app.

The client had one non-negotiable requirement. The marketplace had to run with no one on their side in the loop: nobody approving accounts, nobody working out payments, nobody chasing background checks. Everything had to happen on its own. I was the only backend engineer, building the API that the client’s mobile apps and their admin web frontend ran on.

What I built

• The marketplace workflow. An owner posts a job for a route that needs cover. Relievers apply, the owner picks one, the trip is tracked from start to finish, and the reliever is paid when it’s done. An owner can also invite a specific reliever, in which case their application is approved automatically. I built the whole flow as a set of job states that move forward as owners and relievers act, so no one on the client’s side has to approve, assign, or close anything by hand.
• Automated payouts. The backend works out what each job pays and sends the money to the reliever through Stripe once the trip is complete. Nobody calculates or triggers a payment manually.
• Background checks. Relievers go through a Motor Vehicle Record check with Checkr before they can do anything on the platform. The check runs in the background: the reliever finishes signing up, the backend sends off the request, and the account is unlocked when a clear result comes back. This was added partway through the project when the business needed it, without reworking the rest of onboarding.
• Real-time chat. Owners and relievers chat inside the app, built on PubNub. One feature the product needed wasn’t supported out of the box, so I put it together from PubNub’s existing features and logic on the backend instead of building a chat server.
• A multilingual API. Everything dynamic the backend sends, including validation errors and push notifications through Firebase Cloud Messaging, comes back in the user’s language. The mobile apps don’t carry any translation logic for backend text.

Key decisions

Make the backend react to events instead of waiting on people. With no admin in the loop, the backend couldn’t rely on anyone to confirm that a payment went through or a background check came back. So every outside interaction is driven by webhooks: Stripe and Checkr tell the backend what happened, and the job or account moves to its next state on its own. The alternatives were polling those services or leaving a status for someone to confirm, and both put a person or a timer back in the loop.

Work around the chat provider’s gap rather than replace it. PubNub covered nearly everything the chat needed, except one feature. Building a custom WebSocket server to get it would have meant owning real-time infrastructure for the whole product to close one gap and set the timeline back by weeks. I combined PubNub’s existing features with logic on the backend to get the same behaviour. It’s still how the chat runs today.

Localise on the backend, not in each app. Validation errors and push notifications are generated by the backend. Translating them in the app would have meant every client carrying its own copy of those messages and keeping it in sync. Doing it on the backend, keyed to the user’s language, gives one place to maintain, and any new client gets it for free.

How it went

The app launched with very few backend issues found in QA. I was the only backend engineer, working alongside the client’s mobile team, and owned the API, the data model, and every integration end to end. My work wrapped up at launch.

What I’m most pleased with is that the zero-admin requirement held. The job workflow, payouts, background checks, and chat are still running in production without anyone on the client’s side stepping in, which was the one thing the business needed from the backend.