QuickFlow

I met the owner of a wholesale distribution business by chance at a restaurant. He started describing the software he was paying for, and it was the specific kind of complaint you only get from someone who uses a thing every day.

Grid actions that looked clickable and did nothing. Simple tasks buried behind screens that existed for somebody else's org chart. Hours a week of manual re-entry that a script could have done. He was paying a subscription for the privilege.

None of that came out of a research plan. It came out of dinner, which is the only reason I heard the version with the frustration still in it.

The first thing I built was not a product. It was a set of Excel scripts that took the worst of the manual re-entry off his desk that week.

Two reasons. It gave him something back immediately, before I had earned any right to redesign his operation. And writing them taught me the workflow properly, which no amount of asking would have done, because the parts people forget to mention are exactly the parts they do without thinking.

The product grew out of those scripts rather than replacing them. Everything in it is something the spreadsheet was already doing badly.

I drew the whole thing as a map first. Nine areas off the login, and the argument was about which nine.

The Recipe Calculator sits at the same level as Orders, which looks wrong until you know this business sells to restaurants that price by the plate. Delivery owns the driver interface and location sharing rather than hanging off Orders, because on the day it matters the driver and the order clerk are two different people with two different phones.

Order management is where this business actually lives, so it gets the whole screen and the four numbers that matter across the top: total, pending, delivered, revenue.

Every row carries its customer, its value, its status and its date, and the actions are three direct controls rather than a menu. That is a straight response to the grid he was complaining about, where the controls looked live and were not.

Most of the orders in a business like this are the same orders, every week, from the same accounts. Harbor Cafe every Monday. Fresh Seafood every second Wednesday.

So recurring schedules are their own area rather than a setting inside an order, and they are designed for a phone. The person checking whether Friday's standing orders went out is not sitting at a desk when they think to check.

Inventory, product edits, analytics and the driver views are all designed at phone width first. That is not a responsive-design box being ticked. In this business the warehouse, the van and the office are three different places, and only one of them has a monitor in it.

Designed and built by me, from the site map through the interface to the working application, with AI doing the parts of the build I would otherwise have handed to an engineer.

I am deliberately not putting an outcome number on this page. The honest position is that it came out of one conversation with one owner and it does the job he described; I have not measured it, and a percentage I could not defend on a call is worth less than saying so.

What this one is evidence of is the front half. Hearing a real problem in the wild, relieving it with a spreadsheet inside a week, and only then designing the thing properly.