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 live projects sit behind that: Food Magnet, a food truck discovery and vendor platform, and Koor, a homemade-food ordering marketplace. Neither is a food truck ordering app on its own. Fixed price after a free 30-minute discovery call.
What is included in a food truck ordering app build?
Base scope is what our two shipped food platforms already 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 project evidences which matters. Food Magnet's record covers discovery, live location tracking, menus, vendor profiles and four roles, and describes no customer ordering or checkout flow. Koor's record covers ordering and live order status, on home chefs rather than trucks. The proposal says which half each line came from.
Anything neither project evidences sits outside base scope. We have published no work on point-of-sale hardware, kitchen printers or accounting systems, so we will not put them 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 what Koor's case study describes than to Food Magnet's. Say which one you are on the call, because the two scope differently.
Which builds prove DevoraX has done this before?
Two, both live, both with a full public case study on this site. Between them they cover the two halves of this page, and neither covers both on its own.
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 food truck location tracking is a named part of the stack, and the platform has four user roles: admin, manager, vendor and customer. It is published at foodmagnet.app, on Google Play under com.foodmagnet.foodTruck, and on the App Store. Its record covers discovery, tracking, menus and vendor engagement, not a customer order flow, and the study states we have not published what Stripe charges or on whose behalf. The recorded outcome is descriptive rather than numeric: increased vendor visibility and real-time discovery for customers.
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. The client reports 120,000+ completed orders and a 4.8 out of 5 user rating. The customer app is on Google Play under com.koor_user.
How does live location tracking work when the vendor keeps moving?
Live location tracking is named in Food Magnet's stack, but we have not published how it is implemented, so what follows is general reasoning rather than an account of that code.
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. We have not published either project's permission table, so the structure is what we can state and the rules inside it 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 2019 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.
Every project we deliver gets a published case study, including the parts we could not evidence. Food Magnet's study states plainly that its outcome carries no metrics and that the tracking implementation was never published. Twenty-five delivered projects, twenty-five public studies.
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, we have not shipped those and will not learn on your budget. 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 and its record describes no order flow. 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 24/7 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