Planr Flow

The problem

A lot of companies still run their facilities by hand, without a system that actually fits the work. Orders live on paper, in a spreadsheet, or in someone's head, and the process holds together because the people running it are good at their jobs, not because the tools are. The alternative is a custom system built for the company, and for most of them that is simply too expensive to build and maintain. So they keep going with what they have, and the picture of what is actually happening slowly drifts away from reality.

At its core, Flow is built around a clear pipeline. Every order moves through clearly defined stages, and each stage knows what it needs before the work can move forward. Nothing falls through the cracks, because the system makes the next step obvious instead of leaving it up to memory. Teams can see at a glance what is waiting, what is in progress, and what is done, and they can trust that the screen in front of them reflects the real state of the business rather than a snapshot from three hours ago.

Building it

I worked on Flow as both developer and designer, which meant I got to shape the product from the interface all the way down to the data model. On the design side, the goal was to make a tool that feels light to use even when there is a lot going on underneath. Dense tables, quick filters, keyboard-friendly navigation, and a layout that stays readable whether you are managing five orders or five hundred. I spent a lot of time on the unglamorous parts like empty states, loading states, and error messages, because those are the moments where software usually feels broken, and getting them right is what makes a product feel calm and trustworthy.

On the development side, the stack is Next.js and TypeScript, with Tailwind handling the styling. Server components keep the initial loads fast, while the interactive pieces stay snappy and responsive. Optimistic updates make actions feel instant, so the interface reacts the moment you click instead of waiting for a round trip to the server. Under all of that, a carefully thought-out data model does the quiet work of keeping every view consistent, so the dashboard, the order list, and the detail page never disagree about what is true.

The data lives in Postgres, hosted on Neon, with Prisma sitting on top as a typed layer between the database and the app, so the shape of the data is checked at compile time instead of blowing up in production. Authentication runs on Better Auth, which keeps sessions and sign-in flows secure without dragging in a heavyweight third-party service. Realtime is where Flow really earns its keep: Pusher pushes order updates to every connected client the instant something changes, so a status that moves on one screen moves on everyone else’s at the same time, with no refresh. Upstash Redis handles the fast-moving work underneath, caching hot queries and rate-limiting the API so a busy team never slows the whole thing down. And Sentry watches the edges in production, catching errors with enough context that I can usually fix a problem before a customer even thinks to report it.

One of the more interesting challenges was handling the messy reality of how companies actually work. No two teams run their process exactly the same way, so Flow had to stay flexible without becoming overwhelming. The answer was sensible defaults that work out of the box, with room to adjust as a team’s needs grow. You should be able to start using it in minutes, not days.

What’s next

Planr Flow is still actively evolving. There is a roadmap full of ideas around reporting, automation, and integrations with the other tools companies already rely on. But the guiding principle stays the same: take something that used to be stressful and scattered, and make it feel calm, clear, and under control.