Building systems at a company I cold-emailed

Context

JuicyBite, part of Korkio Company, makes Korean-style frozen meat: marinated chicken breast, smoked duck, and spicy Sichuan-style pork, beef and duck. It sells to Korean and Asian supermarkets such as H Mart and Weee, and to distributors across the US.

Korean meat products can’t simply be shipped into the US, so everything is made here. The company doesn’t own a factory. Two contract plants in Illinois produce everything from raw materials the company owns.

I joined in 2026 after a cold email. It’s a small team, the CEO and a handful of people, so I ended up owning several things at once. This piece is about the back office.

The problem

Every purchase order arrived as a PDF attached to an email. Someone read it, typed the numbers into a bill of lading,¹ typed them again into an invoice, and emailed everything back. It took more than thirty minutes per order, and mistakes were routine: wrong barcodes, wrong quantities, wrong prices.

The paperwork was also more tangled than it looked. One order could be split across both plants, which meant several shipping documents for one purchase order. Orders didn’t list case weights, so those had to be calculated from product specs. Customers used different names for the same product than we did, so lines had to be matched by product code. And every customer wanted a different invoice format.

What I did

I’m not an engineer. I built this by connecting tools that already existed, a database, an automation platform and an AI model that reads PDFs, and writing small scripts to hold them together.

The normal path

You forward the order email, and the rest happens on its own. The AI reads the order and extracts the lines. A person confirms the extraction. A quote is created. The CEO approves by replying “OK” to the email. The shipping documents and invoice are generated and sent back into the same email thread, so the whole history of an order lives in one place.

Cleaning the data first

Before any of that could work, I had to fix the data itself. Two products had swapped barcodes. One barcode was assigned to two different products. Automation built on that would only have made the same mistakes faster.

The exceptions

Most of the work was in cases that only show up in real orders:

The same product, twice. When an order included a product as a paid line and again as a free sample, the second line overwrote the first. I changed the logic to add lines together instead of replacing them.
Replies matched to old orders. Every message to the shared inbox began its thread ID with the same 48 characters, so the system kept matching new replies to orders it had already processed. It needed a status check, not just a text match.
“Paid 7/10.” A customer’s reply about a payment on July 10 was read as a payment of $7. Now the system only treats something as an amount if it comes with a dollar sign.
The broken file. For days, the system produced PDFs that were about 40 bytes long and wouldn’t open. The automation platform was quietly corrupting the file’s encoding in transit. Finding that took longer than any workaround would have, and it was the only real fix.
An error that lied. One step failed with a permissions error. It wasn’t permissions. I had renamed a table, and the old name was still being called. The error was the system’s best guess, and it was wrong.
The path nobody had used. When I tested partial payments, which had never happened yet, the system crashed: an option had been saved with a blank name. In real life, that would have stopped collections the first time a customer paid part of an invoice.

Making it safe to change

People change orders. So I made it possible to reply to the order summary with corrections, a different quantity, pallet count or freight charge, and have the system re-read and re-summarize the order. I also added a gate so no order could be confirmed until the warehouse pickup date was known.

By mid-July the system had passed a ten-step test on a real order, from the forwarded email all the way through a partial payment to a closed invoice.

What I learned

Automation is mostly deciding where the line between people and machines goes. Machines calculate, generate and send. People check.

The difficulty lives in the exceptions, not the normal path. Every serious bug above came from a real order doing something reasonable that I hadn’t imagined. And the paths you haven’t tested always have bugs, because nobody has asked them anything yet.

Finding the real cause was always faster than working around it, even when it didn’t feel that way at the time.

A bill of lading is the document that travels with a shipment and lists exactly what is being moved, from where, to whom. ↩