9 Bean Rows · Suttons Bay, MI
A bakery website connected to the kitchen's ordering system
The situation
9 Bean Rows runs a bakery, café, farm, and wholesale operation out of Suttons Bay. Their wholesale side runs on Orderspace, which holds every product, price, description and photo — 53 categories covering everything from sourdough to catering platters to event tickets.
Orderspace is built for wholesale buyers with accounts, and it does that job well. But a retail customer who wants a Thanksgiving pie, a croissant platter for a meeting, or two seats at a farm dinner isn’t going to set up a wholesale portal login, and shouldn’t have to.
So those orders came in the way they always had. Phone calls. Emails. Notes taken at the counter. Somebody then retyped each one into Orderspace so the kitchen would see it. Every retyping is a chance to get a date, a quantity, or a name wrong — and the ones that go wrong are the holiday pre-orders, where a mistake means a customer without a pie on Thanksgiving morning.
The obvious fix is a website that takes orders. The harder problem is that a website means a second catalog, and a second catalog means maintaining prices and photos in two places forever. That’s where projects like this usually fail.
What I built
store.9beanrows.com, a Shopify storefront, plus two automations that keep it and Orderspace in step.
Orders flow in. Every 30 minutes, around the clock, new website orders are copied into Orderspace with their line items, pickup dates, and customer notes. The bakery sees them in the same place they see everything else. Nobody retypes anything.
The catalog flows out. Every three days, products, prices, descriptions and photos push from Orderspace to the website. Orderspace stays the single source of truth — staff update a price where they already work, and the website follows. There is no second catalog to maintain.
Staff decide what’s public. Not all 53 categories belong on a retail site. Rather than hardcoding that list, the enabled categories live in a table somebody can edit. Turning a seasonal category on for the holidays is a switch, not a support ticket. Currently 40 of the 53 publish.
Building for the bad days
Any automation works on the day it’s built. What matters is what it does on the busiest weekend of the year, when something unexpected arrives.
Nothing is ever deleted. The worst either automation will do is hide a product or send someone an email. There is no code path that destroys data.
Problems are reported right away, and the order still goes through. When a website order hits something strange — a shopper whose email matches a wholesale account, a name that collides with an existing customer — the order goes through on a fallback account and staff get an email explaining what happened. A paid order is never lost to an edge case in the plumbing.
It was handed over, not just delivered. The system ships with an operating guide written in three layers: how it works, for everyone; symptom-cause-fix for office and bakery staff; and full technical reference for whoever maintains it next. Staff resolve the common problems without calling me. That’s the point.
The results
- Around 290 orders have come through the site since launch. Not one was retyped into Orderspace by hand.
- Average order value is up roughly 4x — customers went from testing a single item to placing real pre-orders.
- Peak month: 67 orders, in a business that had no online ordering at all the year before.
- Every top seller is something the bakery couldn’t sell without a phone call — deep dish quiche, croissant platters, celebration cakes, and sold-out seats at three Farm to Table dinners.
That last point is the one that matters. The site isn’t taking sales away from the counter. It’s capturing the orders that used to require someone to pick up the phone, or that simply never happened.