Real-Time Order Management Platform

Before the platform existed, order operations ran through a fragmented set of steps rather than one coordinated system, and staff had no reliable way to know an order's status the moment it changed. That gap between what was actually happening to an order and what staff could see forced people to work from information that might already be out of date, which is a slow and error-prone way to run anything that depends on knowing where things currently stand.

The client needed a single mobile-first platform staff could use directly on the floor, built for the people actually handling orders in real operating conditions. That requirement shaped everything downstream: the interface had to be quick to use in the middle of physical work, and it had to be trustworthy enough that staff would rely on it consistently. A platform is only as good as the server behind it, and it needed a server that could handle media, notifications, document generation, and heavy background work without blocking the user: none of that is lightweight work, and running any of it synchronously in the request path would have reintroduced the same kind of friction and delay the platform was meant to remove.

Underlying both requirements was a single goal: keeping everyone looking at the same live data. In an operation where order status changes constantly and staff act on what they see in the moment, a stale screen is not a minor inconvenience. It reproduces the same fragmentation the platform was meant to solve, just relocated from separate disconnected systems to a single system showing outdated information. Meeting that goal meant treating real-time consistency, not just mobile access, as a core requirement of the platform from the start.

The architecture follows directly from those requirements: real-time accuracy on the client side, and a server able to absorb heavy work without slowing anyone down.

• Separating the mobile client from the API let the two move independently: the Flutter app could iterate on the on-floor workflow without waiting on backend changes, and the API could serve that client without being tied to a specific UI. Keeping the API stateless and securing it with JWTs meant there was no server-side session state to manage or synchronize, which matters for an API expected to serve many devices moving around a floor rather than staying pinned to one connection. Using Prisma over PostgreSQL added type-safe queries on top of that split, catching data-shape mismatches at compile time instead of letting them surface as runtime errors against live order data.
• Order status is exactly the kind of data that goes stale the moment it is fetched once and left on screen, so pushing updates over WebSockets rather than waiting for the client to poll or refresh keeps every connected device showing the same state as it changes. This is what makes the "same live data" requirement real in practice rather than aspirational: staff do not have to manually refresh or wonder whether what they are looking at reflects the latest action taken by someone else on the floor. It also closes off a whole category of the old fragmentation, where two people could otherwise be working from two different pictures of the same order.
• Media processing, notifications, and document generation all take real time to complete, and doing any of that work inline in a request would have blocked the user in exactly the way the platform was designed to avoid. Routing that work through a durable queue instead lets the API respond immediately while the heavier tasks process in the background. Building the queue on pg-boss, which runs on PostgreSQL rather than requiring a separate message broker, kept the operational footprint simple while still providing durability, so jobs survive restarts, traffic bursts get smoothed out instead of overwhelming the server, and failed jobs are retried automatically rather than silently dropped.
• Storing media across both S3 and GCS rather than committing to a single provider spread that dependency instead of concentrating it in one vendor. Sharp handled the image-processing side of the media pipeline: necessary work for a platform handling photos from the floor, but expensive enough that it belongs in the background queue rather than the request path. PDFKit covered document generation, producing the paperwork order handling requires without someone assembling it by hand, and documenting the API with Swagger gave the client a clear, testable contract to build against instead of requiring anyone to reverse-engineer behavior from the code.

• Instead of piecing together an order's status from multiple disconnected sources, staff now work from one mobile-first workflow that reflects the current state of every order as it happens. That consolidation is what actually resolves the original fragmentation problem, not by adding a new tool alongside the old process, but by replacing the fragmented process itself with a single always-current view.
• Because media processing, notifications, and document generation run through the background queue rather than inline, the app stays responsive to the person using it even when a lot of that heavier work is happening at once. Activity on the floor does not arrive evenly, and a queue that smooths spikes rather than letting them back up against the user is what keeps the interface usable during exactly the moments that matter most.
• Generating PDFs and QR codes automatically took work that used to require someone to assemble or produce by hand out of the everyday order-handling process. Removing those manual steps is a small change on any single order, but multiplied across the routine handling that happens on the floor every day, it is the kind of friction the platform was built to eliminate.