Food Magnet: Vendor

What is Food Magnet, and what did Sameem work on?

Food Magnet sells food-truck owners a way to stay findable. Its site, foodmagnet.app, presents a location-display device and a mobile app that together broadcast a truck's live location and menu to customers, and lists plans for vendors. The vendor app is published by FoodMagnet Inc as Food Magnet: Vendor on the App Store and on Google Play. The product's stack is a Flutter mobile app, a React.js admin dashboard and a backend of AWS Lambda functions, with Firebase for realtime updates, Firebase and OneSignal for push notifications, and Stripe for payments.

Sameem worked on Food Magnet as an engineer at Zencloud, on a product that already existed rather than one started from scratch. His work covered responsive web apps in React, TypeScript and Tailwind CSS, vendor dashboards and admin panels, real-time GPS location tracking, dynamic menus, bookings, user analytics and subscription management, serverless backend APIs on AWS Lambda, and Apple Pay and Google Pay integration, along with work on the mobile apps. The sections below explain the engineering behind a product of this shape.

Why is a food truck's location a hard data problem?

The defining property of a food truck is that it moves. A restaurant has an address, and an address can be indexed once and relied on for years. A truck's position is a value with a short useful life. Customers need current menus, accurate locations and vendor profiles, and two of those three are perishable. A conventional directory stores location as a static field written at signup, and everything downstream of that field, such as search, ranking, caching and messaging, is built on the assumption that it stays true. Remove the assumption and the same information has to be modelled as state that changes during a working day rather than as profile text entered once.

For a business without fixed premises, visibility is not a listing. It is the continuous availability of current information to people who are nearby now. That pushes the engineering weight of a product like this towards freshness. Vendor profiles, menu management and payments are well-understood problems with well-understood solutions. What decides whether the product is useful is whether the location a customer sees matches where the truck actually is, which is a question about write paths, propagation and staleness rather than about feature count.

How is the platform architected across mobile and admin?

The platform is two clients over one backend: a Flutter mobile app and a React administrative dashboard, with the backend built from AWS Lambda functions. The architecture is component-based and serverless, and that phrase maps onto the two halves of the system: components on the clients, functions on the server. A mobile client and an administrative web client are different products with different interaction models, deployment channels and release cadences, and serving both from a single codebase usually compromises whichever one was not the primary target. Splitting them lets each client use the framework that suits its surface, while the data and the rules governing it stay in one place behind both.

The boundary between clients and backend has to be drawn firmly. The platform has four user roles: admin, manager, vendor and customer. Role boundaries implemented in two separate client codebases are two implementations of the same policy, and two implementations drift. Put them behind the Lambda layer and there is one answer to what a manager may change and what a vendor may not, whichever client asked. The same logic applies to the data itself. A menu edited through the dashboard and read on a phone should be one record with one shape, not two representations kept in approximate agreement by convention. A serverless backend does not enforce this by itself, but it makes the shared layer the obvious home for those rules, because it is the only component both clients touch.

How does live location tracking work in a product like this?

Live location is the product's central feature. foodmagnet.app presents a location-display device that updates a truck's position automatically, so the vendor does not have to update it by hand, and real-time GPS location tracking was part of Sameem's work. The first point a feature of this kind has to resolve is that position is continuous state rather than a request-response value. A truck's location is not set once and read thereafter. It changes while the vendor is working and loses its worth as it ages, so the system needs a write path that runs on its own schedule rather than only when someone taps something. Most of the design decisions follow from that property, and most of the difficulty sits in the write path rather than the read.

On a phone, the tension is between truthfulness and cost. Sampling position often keeps the data accurate and spends battery and mobile data on a handset the vendor is also using to run a business, while sampling rarely inverts both sides of that trade. Mobile platforms expose movement-triggered location callbacks because a fixed timer is the wrong instrument for a value that only changes when something moves, and a dedicated device takes that load off the vendor's phone altogether. On the reading side the question is proximity, a spatial query with a freshness constraint attached, and the failure mode deserves as much design attention as the normal case. A position that cannot be refreshed is better shown as unknown than as a last known value presented with the same confidence as a live one, because a confident wrong answer costs a customer a wasted journey.

Why does a serverless backend suit this kind of workload?

The backend is built from AWS Lambda functions, and Sameem built serverless APIs on it. Lambda scales on concurrency, which is a statement about simultaneity rather than totals. The unit of capacity is the in-flight invocation, acquired when a request arrives and released when it returns, so capacity is held for exactly as long as work is running. Nothing has to be sized in advance against a forecast and nothing has to be reclaimed afterwards. For a consumer-facing backend, where load is produced by customer behaviour rather than by something the operator schedules, that removes a class of capacity decisions which would otherwise be made on incomplete information.

The shape of the work suits function execution as well. The operations such a platform implies, location writes, proximity reads, menu fetches, profile reads, bookings and payment webhooks, are short, independent of one another and dominated by input and output rather than computation. None of them needs a long-lived process holding state between calls, which is the characteristic that makes functions a good fit. The trade is real. Functions that have gone idle pay a cold start on their next invocation, and state that a persistent server would have kept in memory has to be fetched from a data store or cache instead. Those costs are bounded and predictable, which makes them easier to accept than a provisioned tier sized by guesswork.

How do payments, realtime updates and notifications fit together?

Stripe is the product's payment provider, and Sameem integrated Apple Pay and Google Pay and built subscription management. The general case for a payment provider is that it keeps raw card data out of the platform: card details are captured by the provider's components or by the phone's wallet, and the platform handles a token instead, which removes the most sensitive class of data such a system would otherwise store, transmit and be answerable for. Wallet payments go a step further: the merchant receives a device-specific token rather than the card number itself. The cost is that authoritative confirmation arrives asynchronously, over a webhook, rather than in the response to the request that began the payment. Webhook delivery is at-least-once by design and retries can arrive out of order, so every handler has to be idempotent: processing the same event twice must leave the same state as processing it once.

Firebase does two jobs in the stack, realtime updates and, alongside OneSignal, push notifications, and the division of labour between those channels is the useful part. A realtime subscription keeps a screen someone is looking at in step with the backend without the client polling for changes it will usually not find, which matters on mobile, where every poll costs battery and data whether or not anything changed. Push notifications solve the opposite condition: reaching a device whose app is closed, which is the state most apps are in most of the time. The architectural point is that a subscription and a push are different transports suited to different conditions, and a product carrying both is choosing between them per situation rather than sending the same thing twice.

What do the four user roles mean for the backend?

There are four user roles: admin, manager, vendor and customer. Four roles across two clients is exactly the configuration in which authorisation tends to go wrong, because each client can appear to behave correctly while enforcing a slightly different reading of the same rule. A client-side check 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 sent without going through the interface at all. The boundary has to sit where every client passes through, which in this architecture is the Lambda layer. Serverless does not provide that for free: each function can be invoked independently, so a shared authoriser is what stops the policy fragmenting across the set of functions.

The roles also explain why the administrative dashboard is its own client rather than an elevated mode inside the mobile app. Two of the four roles, admin and manager, are operational rather than participatory: they act on other people's records rather than their own. That is a different relationship to the data, and a separate web client serves it better than a privileged branch inside the mobile app, both because the work differs and because keeping operational capability out of the installed app limits what a compromised session can reach. Vendor dashboards and admin panels were part of Sameem's work.

Where can you see Food Magnet?

Food Magnet's vendor app is published by FoodMagnet Inc as Food Magnet: Vendor on the App Store (id6444549450) and on Google Play (package com.foodmagnet.foodTruck). The product's site is foodmagnet.app, which presents the location-display device, the menu display and the plans on offer. Those are the places a buyer can check today.

Shipping to both stores is part of the case for this stack. A single Flutter codebase produces both mobile builds, so the iOS and Android apps do not drift apart between releases, while the React dashboard is a separate web client deployed on its own schedule without waiting for store review. All of them meet at the Lambda layer, which is the only place where every client agrees on what is currently true about a truck.

Why this stack

• Flutter (mobile app): one Dart codebase produces both the Android and iOS builds of the vendor app, so the two store releases do not drift apart. Flutter compiles ahead of time to native code and draws its own widgets rather than bridging to platform views, which keeps frame-by-frame work, such as a map redrawing markers as they move, inside the framework rather than across a bridge. For a product whose central feature is live location, the screens that update most often are the ones a bridged runtime serves least well.
• React.js (admin dashboard and web apps): Sameem built responsive web apps, vendor dashboards and admin panels in React, TypeScript and Tailwind CSS. An administrative client is largely repeating structures rendered many times with different data, which React's component model expresses directly, and its rendering approach suits interfaces where many small pieces of state change independently, updating only what changed rather than reloading a page. TypeScript adds a checked shape to the records the dashboard edits.
• AWS Lambda Functions (backend): Lambda scales on concurrency. The unit of capacity is the in-flight invocation, acquired per request and released when it returns, with nothing provisioned in advance against a forecast. The work suits function execution too, since location writes, proximity reads, menu fetches, bookings and payment webhooks are short, independent and bound by input and output, with no long-lived process state to keep warm. The trade is cold starts on idle functions and state that must be fetched rather than held in memory.
• TablePlus (database): TablePlus sits under Database in the stack, but it is a desktop database client rather than a database engine, so this entry is about tooling. A GUI client is how a developer reads and writes stored state directly, outside application code. That carries more weight in a serverless system than a monolithic one, because logic is spread across many short-lived functions with no long-running process to attach to.
• Cloud Storage: the architectural reason object storage sits beside a function-based backend is that Lambda invocations have no durable local disk and no guarantee of reusing the same machine. Anything that must outlive a single invocation has to live somewhere every invocation can reach, and object storage provides that while leaving the compute tier stateless.
• Firebase (realtime and notifications): a position that changes through a working day is better delivered as a stream of changes than fetched by repeated polling, because polling on a handset spends battery and mobile data on requests that usually return nothing new, and still leaves the screen stale between them. A subscription inverts that: the backend pushes each change down a connection that is already open. Firebase supplies that channel and a push delivery path beside it, which is why it is listed under both realtime and push notifications.
• Stripe, Apple Pay and Google Pay (payments): Stripe is the payment provider, and Sameem integrated Apple Pay and Google Pay. Delegating card capture keeps raw card data out of the platform: the provider's components or the phone's wallet take the card and the platform holds a token, removing the most sensitive class of data the system would otherwise store and transmit. The integration cost is webhook discipline. Confirmations arrive asynchronously and delivery is at-least-once, so handlers must be idempotent, reaching the same state whether an event arrives once or several times.
• OneSignal (push notifications): Firebase and OneSignal sit together under push, and running both is a layering decision rather than duplication. Firebase Cloud Messaging and APNs are the transports that actually reach Android and iOS devices, while a notification service sits above them and handles cross-platform addressing, segmentation, scheduling and delivery reporting, so that logic does not end up inside request handlers.