The Order Status Nothing Could Tell Apart From an Inquiry

Bakery Buddy's order pipeline has a gap between Inquiry and Invoice Sent. Someone asks about a cake, and at some point later a price goes out the door. Somewhere in between, Marin makes a real decision: I'm taking this one, or I'm not. For most of this year, that decision left no mark on the order at all.

Twice, I tried to give it a name. Both times, real bakers used the app for days without a single order ever landing on it, and I took the status back out.

A hole shaped like "we're taking this"

Before any of this, `orders.status` already had a status called `declined`. It had been sitting in the column's allowed values since the very first schema, and it had never once been written. Zero of 783 real orders. No screen set it, no importer produced it, and the one place that could, a raw status dropdown on the edit page, nobody had ever used to pick it. It also didn't mean anything different from `cancelled` anywhere downstream, same badge color, same filters, same terminal-status lists. Its only real effect was making "did we turn this down, or did the customer disappear?" an unanswerable question with two statuses and no data behind either one. I dropped it and made `cancelled` the single terminal-negative status, with the actual reason living in a text field instead of a second status. That part held.

What it didn't fix was the actual hole. An inquiry could sit forever, or jump straight to a quote. There was no way to say "we're doing this one" that wasn't also "here's the price," and no way to filter for "inquiries I haven't answered yet" as distinct from "inquiries I haven't looked at." Marin does turn work down. That decision needed somewhere to live.

The first name for it didn't get a chance

The first fix for that gap was a status called `payment`, sitting between Inquiry and Invoice Sent since the earliest version of the schema. Nobody remembers exactly what it was supposed to represent. What's checkable is what it actually did: zero rows, across all four bakeries on the platform, for its entire life. Nothing wrote it, nothing read it, and it still rendered as a real box in the order-status stepper, so every single order visually skipped a step on its way from Inquiry to Invoice Sent. It was dead weight with a UI footprint.

I retired `payment` and put `accepted` in its place in the same migration, because the actual product question, "has the baker agreed to take this job," was still sitting there unanswered.

The second attempt did everything right, and still landed at zero

`accepted` was not a placeholder. It got a real green checkmark on every inquiry row, an "Accept order" entry in the row's More Actions menu, and a bulk-bar Accept for clearing a screenful of inquiries at once. It was wired into the sets that actually move an order forward: the active-status list, the payment-schedule bucket logic, the set of statuses a refund can move an order out of, the set `paidStatusPatch` treats as pre-payment. Accepting an inquiry was a real, reachable, forward-moving action, not a dead end with nowhere else to go. The stepper grew a fifth box: Inquiry, Accepted, Invoice Sent, Scheduled, Completed, all five reachable.

Three days later, across all four bakeries on the platform, it had exactly as many rows as `payment` had ever had. Zero.

Wired forward is not the same as read differently

`accepted` failed for a completely different reason than `payment` did. `payment` failed because nothing could reach it. `accepted` failed with a working button sitting right on the row, and bakers still didn't use it, because using it bought them nothing they didn't already have.

It was deliberately left out of the list of statuses a follow-up automation can chase for payment, out of the digest that tells a baker what's overdue, and out of the pricing-comparables logic, correctly, since an accepted order still has no agreed price. No automation triggered on it. No report changed shape because of it. An order sitting at Inquiry and an order sitting at Accepted looked and behaved identically to every single downstream reader in the app. Clicking Accept cost a baker a tap, and every consumer of that data acted exactly as if she hadn't clicked it. There was no reason to ever reach for it over just sending the estimate straight from Inquiry, which is the one action that actually did visibly move the order and end the ambiguity.

I took `accepted` back out, along with the checkmark, the menu entry, the bulk action, and the fifth box in the stepper. The filter tab and dashboard funnel stage for it went too. Both had read zero the entire time they existed.

What actually moves an order off Inquiry now

There's still no Accept action anywhere in Bakery Buddy today, not on the row, not in More Actions, not in the bulk bar. The one event that moves an order off Inquiry is sending the estimate itself. If no estimate has gone out, the order is still an Inquiry, however sure the baker is in her own head that she's taking the job. Declining still gets no status of its own; the reason goes into a text field on the order, exactly the same fix that closed out `declined`.

What generalizes past order statuses

A new state in any pipeline is a cost you pay up front. Every downstream reader now has one more case to get right, one more list it either belongs in or doesn't. That cost only earns itself back if at least one of those readers treats the new state differently than the state it replaced. If the honest answer to "what changes when this is set instead of unset" is nothing, don't expect anyone to bother setting it, no matter how reachable the button is.

`payment` failed the obvious version of that test: nothing could even reach it. `accepted` is the more useful failure, because it passed every mechanical check I could think to run, real button, real wiring, real forward motion, and still failed the only check that actually mattered: did anything on the other end act differently because of it. It didn't. So bakers, correctly, skipped straight past it to the action that did something. It's a close cousin of a mistake I'd already made once in this same app, in a completely different corner of it: four different screens once showed four different numbers for the same thing, because each one quietly decided for itself what counted. A status nobody reads differently is the same failure with the arrow pointing the other way, a decision that gets recorded and then nothing reads.

Before you add a state to any pipeline, name the specific downstream thing that will do something different because of it. If you can't name one, you're not adding a status. You're adding a button nobody has a reason to press. You can see the rest of how Bakery Buddy's order pipeline actually works today at Bakery Buddy's cake business software.