BiteTaps is a six-product delivery platform with its own rider network: four apps, two web panels, one backend. Restaurants keep the commission that third-party platforms take, and get a tool that proves the saving before they sign up. Live on the App Store and Google Play.
Order volume, vendor count and rider earnings belong to the client and aren't ours to publish. What's on this page is what was built, why it was built that way, and the parts that were harder than they looked.
A restaurant selling a $25 order through a major delivery platform typically hands over a quarter of it in commission. On thin food-service margins that is often the entire profit on the order — restaurants take the listing because the orders come with it, and absorb the loss because refusing means losing the customer to the restaurant next door that didn't refuse.
BiteTaps is the alternative: a multi-vendor marketplace with its own rider network, where merchants pay a self-delivery rate instead of platform commission. That required six products rather than one — a customer app, a rider app, a merchant app, a third-party order tool, an admin panel and a vendor web panel — all agreeing with each other about the same order, the same rider and the same money.
A delivery platform without restaurants is an empty app. And a restaurant owner already on Uber Eats and Grubhub has heard the pitch before — everyone claims to be cheaper. Saying “we cost less” is a sales assertion. Showing them, on their own numbers, what a specific order actually costs on each option is something else entirely.
That turns a marketing problem into an engineering one, because the comparison is not as simple as one percentage against another. A restaurant can charge the customer a delivery fee. That fee offsets what the restaurant pays when it delivers the order itself — but it does not touch the commission a third-party platform charges, because the platform takes its cut of the order regardless. Get that one subtraction backwards and every number you show a prospective vendor is wrong, in your favour, in a way they will notice the first time they check.
Underneath that sat the ordinary difficulty of the thing: six products, four roles, live rider positions, and orders that must never be assigned twice or dropped entirely.
Most delivery platforms build the marketplace and let the sales team argue about pricing. We built the argument into the platform — a tool a merchant uses on a real order, with their own figures, that shows what each delivery route costs and what they keep. Everything else was structured so that six products could stay consistent about a single order.
A merchant enters the order value, the third-party platform's commission percentage, their self-delivery rate, and any delivery fee they charge the customer. MunchDrops returns the cost of each route and the net saving, and it doubles as the entry point for orders that arrived through another platform but will be delivered by a BiteTaps rider. The pitch and the workflow are the same screen.
Third-party commission, self-delivery cost, and customer-paid delivery fee are distinct quantities that interact asymmetrically. Modelling them as three separate inputs with explicit rules — rather than one blended rate — is what makes the comparison survive a merchant checking it by hand.
BiteTaps for customers, BiteRide for riders, BiteTaps Merchant for vendors, MunchDrops for third-party orders. Each ships and updates on its own cadence, each clears store review on its own terms, and a rider never downloads a build containing the merchant's pricing controls.
When an order lands inside a rider's service area, it is assigned automatically, weighted on that rider's current order load, distance to the pickup, and time. Dispatch staff can override any assignment from the admin panel. Automatic routing handles the volume; a human handles the exception the logic didn't anticipate.
Riders earn a base wage plus a flat fee set by service area, plus tips, and request payouts through the admin panel. That is a deliberate departure from the gig model — it makes rider cost predictable for the operator and rider income predictable for the rider, and it removes the incentive to cherry-pick short deliveries.
Order state, rider position and assignment events push over Socket.io rather than polling. When a rider accepts, the customer's tracking screen, the merchant's queue and the admin dashboard all move at once.
The savings calculation looks like arithmetic until you write it down. Then it turns out that one of the inputs applies to one delivery route and not the other, and that getting it wrong produces numbers that are plausible, favourable, and false.
A merchant sees what a specific order costs on each delivery route before committing to anything — the sales argument is a product feature, not a claim.
The comparison is built to understate rather than overstate, so it survives a merchant checking it against their own platform statement.
Fee rules live in one place, so the app and the web panel cannot show different numbers.
Orders route automatically inside a rider's service area, and a human can override any assignment without leaving the admin panel.
Rider pay is base plus area fee plus tips — predictable cost for the operator, predictable income for the rider, no incentive to cherry-pick.
Orders arriving from other platforms still get fulfilled by a BiteTaps rider, so the network earns from demand it didn't originate.
Four separate apps mean each role ships on its own cadence and clears store review on its own terms.
All four apps cleared App Store and Google Play review — eight listings, including in-app purchase and data-safety declarations.
Building a marketplace where the pricing argument is the product?
Customers, riders, merchants and dispatch each get their own product — and every one of them reads the same order record.
Every tool below is in the build — no résumé-ware.
A single customer app is one project; a working delivery business is usually four or five. BiteTaps needed a customer app, a rider app, a merchant app, a third-party order tool, an admin panel and a vendor web panel, because each role needs different screens, different permissions and its own release cycle. We scope marketplaces in phases and quote each phase fixed-price after a free scoping call, so you can launch one side of the market before funding all of it.
On BiteTaps, an order landing inside a rider's service area is assigned automatically, weighted on that rider's current order load, the distance to pickup, and time. Dispatch staff can override any assignment from the admin panel. The override matters more than the algorithm — automatic routing handles volume, but every delivery operation has exceptions the logic didn't anticipate, and a system without a manual path forces staff to work around it rather than with it.
Yes, and it changes the build. BiteTaps riders earn a base wage plus a flat fee set by service area, plus tips, and request payouts through the admin panel — rather than a per-order commission. That makes rider cost predictable for the operator and income predictable for the rider, and it removes the incentive to cherry-pick short deliveries. The earnings model is a product decision with real consequences for the software, not a payroll detail to settle later.
MunchDrops lets a merchant enter an order that arrived through a third-party platform and dispatch a BiteTaps rider to fulfil it, at the standard rate. It also shows what that order costs on each delivery route and what the merchant keeps. It means the rider network earns from demand it didn't originate, and it gives merchants a reason to join before they've moved any of their own volume across.
Usually four, plus panels. Customers, riders and merchants need genuinely different products — different screens, different permissions, different update rhythms. Cramming them into one app with role switching means every rider downloads the merchant's pricing controls, and a bug in one role blocks releases for all three. Separate apps cost more up front and cost far less over the following two years.
Yes. BiteTaps shipped eight store listings — four apps across two platforms — including in-app purchase configuration, account deletion, and privacy and data-safety declarations. Multi-app submissions are their own workstream: each app needs its own listing, screenshots, review notes and compliance answers, and a rejection on one shouldn't hold the other three.
Six products, four roles, one backend — shipped to both stores.
See how we'd scope yours.
Marketplace & On-Demand
E-Commerce & Retail
