Why the shops that need it most are the ones who say no

A cidery in Maine, eleven people on the payroll, good product, steady growth. They'd been shipping into New York State for about two years when the buyer's compliance team sent over a records request. Nothing adversarial about it. Standard verification, the kind that lands in an inbox every month somewhere in this industry.

The owner told me she read the email three times before she opened a spreadsheet.

She knew where everything was. Press dates, tank assignments, the pasteuriser logs, the lot codes on every case that went south of the border. It all existed and it was all accurate. What she didn't have was a way to put her hands on eighteen months of it in the format somebody else wanted, inside the window they'd given her.

Her team got it done. It cost them a weekend, a Monday, and most of a Tuesday, and the production plan for that week went out the window because the two people who knew where the records lived were the same two people who run the floor.

When I asked whether she'd looked at a system, she gave me the answer I hear more than any other in this business. "We've talked about it. We're not really tech people here."

I don't think that's what she meant.

#Everybody in food has a software scar

Ask an owner-operator about their history with software and you'll usually get a story, and it's usually not a good one.

Somebody bought a system in 2019 that was built for a plant running four lines and three shifts. The implementation was going to take four months, then it took nine, then the consultant assigned to the account changed twice. Half the team learned it. The other half kept using the whiteboard because the whiteboard worked. Eighteen months later the subscription was still coming out of the account and nobody had opened the thing since the spring.

That happens often enough that caution is the correct response. If you've been burned by a rollout once, in an operation where one bad quarter is actually a bad quarter, you should be careful the second time.

But the caution gets described using the wrong words. "We're not tech people" sounds like a statement about aptitude. What it's actually describing is risk tolerance, and specifically the amount of disruption a small team can absorb before the product stops going out the door.

"It wasn't that we couldn't figure it out. It's that we had about two hours a week to figure it out and they'd built something that needed twenty."

Those are different problems with completely different solutions. One of them says learn more. The other says the thing you were sold was never sized for you.

#The rules already assume you've got a system

Here's where it stops being a preference.

Under the Safe Food for Canadians Regulations, most licence holders need a written preventive control plan and traceability records that let you trace one step back to your supplier and one step forward to your immediate customer. Those records have to be available on request, and CFIA can ask for them during an inspection, during a complaint investigation, or in the middle of a recall when the clock is the whole problem.

If you're exporting to the States, the requirements stack. Juice producers fall under FDA's juice HACCP rule, with the 5-log pathogen reduction and the verification records that come with it. And if anything you make sits on the Food Traceability List, FSMA 204 expects you to capture specific key data elements at defined points in the supply chain and hand over an electronic, sortable file within 24 hours of a request. The compliance date has moved, which bought everyone some room, but the shape of the requirement hasn't changed and it isn't going to.

Read the 24-hour piece again with a small operation in mind. Not 24 hours to find the information. 24 hours to produce it in a structure somebody else specified, while you're still running production, possibly while you're also managing whatever caused the request in the first place.

A binder can hold that information. A binder cannot produce it in that window unless somebody stops doing their actual job.

So the regulatory floor has already been set at a level that assumes a system. Whether or not the shop considers itself technical was never part of the calculation.

#What "not technical" usually turns out to mean

I've had this conversation enough times now to notice the pattern underneath it. When somebody says they aren't a tech person, they're generally saying one of four things.

The first is the scar above. Burned once, not keen to volunteer again.

The second is money, but not in the way you'd expect. It's rarely the monthly cost that stops people. It's the cost of the transition, the weeks where you're running the old way and the new way at once, and there's no slack in the schedule for that.

The third is that every demo they've sat through was built to impress a different buyer. Dashboards showing plant-wide OEE across multiple facilities, procurement workflows with four approval tiers. If you're eleven people, you're watching a presentation about somebody else's company and politely waiting for it to end.

And the fourth is the one nobody says out loud. The current setup depends on a handful of people who've been there a long time, and putting it into a system means writing down how things actually work, which is a more exposing exercise than it sounds.

"Honestly the part I dreaded was admitting how much of it was just in Dave's head. Turned out Dave was relieved."

None of those four is a statement about capability. Three of them are about risk and one is about pride, and all four are reasonable things for somebody running a small manufacturer to feel.

#The work that stops

What changes isn't the skill required. It's the number of times the same piece of information gets handled.

Right now a weight gets read off a scale, written on a sheet, carried to an office, typed into a spreadsheet, and then reformatted into whatever a customer or an auditor wants. Five touches, five chances to lose a digit, and the person doing the typing is usually the person you most need on the floor.

Capture it once, at the scale, attached to the lot, and the rest of those steps stop existing. The record isn't better because somebody was more careful. It's better because there were fewer opportunities to be careless.

That's what makes audits under an hour possible for shops that used to block out two days for the same thing. The preparation moved. Instead of assembling proof after somebody asks, the proof accumulated while the work was happening.

"First time we did a mock recall with everything in one place, we finished in about forty minutes and I genuinely thought we'd done it wrong."

The other thing that stops is the dependency. Not because anybody gets replaced, but because what one person knows becomes something the operation knows, and that's the difference between a business you own and a job you can't leave.

#So what are you actually saying no to?

If the objection is that software has let you down before, that's fair and you should ask harder questions this time. Ask who else your size is running it. Ask what week two looks like, not week twenty.

But if the objection is that you're not a tech person, I'd push back a little. You're already running batch schedules, cold chain, labelling compliance, customer specs and a payroll, usually without a dedicated person for any of it. The capability question was answered a long time ago.

What's left is a decision about whether the current arrangement is the one you want to be running when the next big order shows up, or the next request lands on a Thursday afternoon.

Book a demo at book a demo. Thirty minutes, and bring a real question off your floor. Tell us what you'd want to know about last Tuesday's production run and we'll show you exactly where the answer would live. If it doesn't fit the way you actually work, you've lost half an hour and we've both learned something useful.