DevoraX builds discovery and ordering apps for food trucks and other mobile vendors, whether you run your own trucks or sign up independent ones. Two products sit behind that. DevoraX's founder, Sameem Amjad, worked on Food Magnet, an existing food truck discovery and vendor platform, as an engineer at Zencloud. He also worked on Koor, a homemade-food ordering marketplace. Food Magnet covers the food truck side, Koor the ordering side. Fixed price after a free 30-minute discovery call.
What is included in a food truck ordering app build?
Base scope is what the two food platforms behind this page contain between them. A customer app that finds nearby vendors and reads current menus. A vendor surface for updating location, menu items, availability and profile. A web admin dashboard for the people who run the platform rather than trade on it. Card payments through Stripe. Push notifications. A realtime channel so an open screen stays in step with the backend instead of polling.
Which product evidences which matters. Food Magnet covers discovery, live location tracking, menus, vendor profiles and four roles. Koor covers ordering and live order status, on home chefs rather than trucks. The proposal says which half each line came from.
Anything neither product evidences sits outside base scope. Nothing in the DevoraX portfolio covers point-of-sale hardware, kitchen printers or accounting systems, so they will not appear on a proposal as though they were routine. Running costs sit outside the fixed price: AWS, Firebase, Stripe fees and store developer accounts are billed to you by those vendors.
Who is this built for?
Three kinds of buyer. An operator who wants a branded ordering app for their own trucks. A platform business signing up independent vendors and taking a cut, which is a two-sided marketplace where the supply side happens to move. And market or event organisers who need the vendors on a site to be findable and orderable from a phone while that site is open.
The common property is that location is state rather than an address. A restaurant can be indexed once and relied on for years. A truck's position has a short useful life, and so does its menu. That one fact changes how search, caching, ranking and notifications have to be built, which is why a generic restaurant ordering template rarely survives contact with a vendor that moves. If your platform is multi-vendor first and mobility is secondary, the weight of the work moves from freshness to vendor onboarding and catalogue structure, which is closer to Koor than to Food Magnet. Say which one you are on the call, because the two scope differently.
What food platform work stands behind this page?
Two products, one for each half of this page.
Food Magnet is a food truck discovery and vendor engagement platform. It runs as a Flutter mobile app with a React admin dashboard over a serverless AWS Lambda backend, with Firebase for realtime updates, Firebase and OneSignal for push, and Stripe for payments. Live truck location tracking is part of the product, and it has four user roles: admin, manager, vendor and customer. Sameem worked on it as an engineer at Zencloud, on a product that already existed. His work covered React and TypeScript web surfaces, vendor dashboards and admin panels, live GPS tracking, menus, bookings, Apple Pay and Google Pay, and AWS Lambda APIs. It is published at foodmagnet.app, on Google Play as com.foodmagnet.foodTruck, and on the App Store as Food Magnet Vendor.
Koor covers the ordering half, on home chefs rather than food trucks. It is a homemade-food marketplace on React Native and NestJS, with Elasticsearch for discovery, Firebase for live order status and AWS for hosting. Sameem worked on it, and the customer app is on Google Play as com.koor_user, first released in October 2025.
How does live location tracking work when the vendor keeps moving?
Live location tracking is part of Food Magnet, and Sameem worked on its live GPS tracking. The engineering problem is the same for any vendor that moves.
Position is continuous state, not a request-response value. It changes while the vendor is working and loses its worth as it ages, so the system needs a write path running on its own schedule rather than only when someone taps something. On the device the trade is between truthfulness and cost, because frequent sampling keeps the data accurate and spends battery and cellular data on a handset the vendor is also using to run a business.
On the read side, proximity is a spatial query with a freshness constraint attached, and the failure mode deserves as much attention as the happy path. A position that cannot be refreshed is better shown as unknown than as a stale value presented with the confidence of a live one. A confident wrong answer costs a customer a wasted journey.
How is vendor, operator and customer data kept separate?
Food Magnet has four roles across two clients: admin, manager, vendor and customer, on a mobile app and a web dashboard. That configuration is exactly where authorization tends to go wrong, because each client can look correct while enforcing a slightly different reading of the same rule.
A check in the client is a user interface decision. It is useful for hiding controls a person cannot use, and it is not a security boundary, because the request it guards can be issued without going through the interface at all. The boundary belongs where every client passes through, which on Food Magnet is the Lambda layer, and on Koor is the single NestJS service allowed to write authoritative order data.
The same reasoning is why an admin dashboard is a separate web client rather than a privileged mode inside the consumer app. Keeping operational capability out of the app customers install limits what a compromised customer session can reach. The rules inside that structure are yours to define.
How does the build run, and what do you need from us?
It starts with a free 30-minute discovery call. We come out of that with enough to write a fixed-price proposal: the screen set, the role model, the integrations, and what is explicitly excluded. You get it in writing before committing to anything. There is no hourly billing, so a scope change is a conversation about a revised fixed price rather than a surprise on an invoice.
What we need from you is short but has to be real. A named person who can make decisions without convening a committee. Your menu and vendor data model, or enough examples that we can derive it. Your own Stripe account, because the money should land in your account and not pass through ours. Apple and Google developer accounts in your company's name, for the same reason.
DevoraX has been running since 2022 and is two people: Sameem Amjad and Usman.
How is this priced?
Fixed price, always, written after the discovery call. Published starting points are MVP Starter from $2,900, Growth from $7,500, and Enterprise custom-scoped. Those are indicative starting points rather than quotes, and a platform with live tracking, four roles, payments and two mobile targets is not a starter build.
What moves the number is mostly surface count and role count rather than a list of features. One customer app on one platform is a different job from a customer app, a vendor surface and an admin dashboard. Four roles cost more than two, because the authorization work behind them is real. Shipping iOS as well as Android adds store review and device testing even where one codebase produces both binaries.
Third-party running costs are yours and not marked up: AWS or Firebase usage, Stripe's processing fees, developer account fees.
What happens after launch, and who owns the code?
You own all code and IP on final payment. No licence-back, no hosting lock, no arrangement where the repository stays with us. It is handed over in your accounts, on your infrastructure, and you can take it to another developer the week after launch.
Support after launch is scoped and quoted separately rather than folded into the build price. We would rather quote it against what the product actually needs once it is live than charge you in advance for a retainer neither of us can size yet.
When should you not hire DevoraX for this?
If you need point-of-sale integration, kitchen hardware, a driver dispatch and routing engine, or a named compliance regime signed off, nothing in the DevoraX portfolio covers those, and your budget is the wrong place to learn them. Hire a supplier with that exact scope already in their portfolio.
If you need a supplier who has already shipped ordering and checkout inside a food truck product, we are not it. Food Magnet is the food truck half. Koor is the ordering half, and its vendors are home chefs. That gap is real and you should price it into the decision.
If you need a contractual delivery date you can hold a supplier to, look elsewhere: we do not publish timelines and will not invent one on a first call to win the work. And if you want a large team, an account manager and a round-the-clock support desk, we are two people. You deal directly with whoever writes the code, and there is nobody else to hand the work to when they are unavailable.
Start with a scoping call
A free 30-minute call to work out what you are building and what is actually hard about it. If there is a fit you get a written fixed-price proposal. If there is not, we will say so on the call.
Book a call