Origin Meals: a complaint that turned into three years of work.

I was a customer first. My wife and I wanted to eat from the same weekly meal plan and could not. The subscription model forced us into two separate accounts, paying twice and managing twice. I wrote in to complain. The founder's reply was: help me fix it.

The problem was not a bug. Shopify and the recurring-billing apps bolted onto it are built for click, buy, fulfill: a customer buys a thing, it ships when it is ready, and the order is a moment. Origin Meals was a weekly production cycle. Orders closed at a deadline, food was cooked across two prep days and went out on two ship days a week, and what a customer subscribed to was not a product at all. It was a pickup location and a day, a CrossFit gym or a chiropractic clinic. Every hard problem over the next three and a half years came out of that gap.

The first phase was the storefront: a restyled Shopify theme carrying a model the platform had no concept of. I worked that model out with the founder before writing much of anything, because he was the one who knew which parts of it the business actually depended on. The cart had to express which location you collect from, which day, the deadline you are ordering against, how often it repeats, and the discount recurrence earns. A standard commerce cart says none of that. Recurring billing moved from Shappify to Charge Rabbit and later to ReCharge, which meant migrating a live subscriber base between platforms: mapping legacy product variants, writing the migration and reconciliation scripts, and moving Stripe payment tokens across. The founder and I sequenced the cutover around the weekly billing run together, since there was no window in which nobody was being charged, and his knowledge of the plans and pricing is what made the variant mapping correct.

The second phase was the harder one, and it was most of the engagement. Once the weekly deadline passed, every recurring subscription had to become a cook list, split across the two prep days that fed the two ship days, sorted by diet and portion size, and printed as labels the pack line could work from. The kitchen was doing this in spreadsheets, re-keyed by hand every week, and the crew knew precisely which parts of that hurt. I designed the replacement with them rather than for them, standing in the kitchen through the weekly cycle and building to what they told me, then revising it as they used it. It became a real application rather than a reporting job: Ruby services behind a Meteor front end on Firebase, giving the kitchen screens to work from. Weekly order ingest with an exception log that surfaced malformed rows rather than discarding them, production reporting by meal period and diet and portion, and label generation for the pack line. The two cook days and the two ship days are the same two days, which is why the system's central output is a split rather than a total.

Alongside it: multi-region support as the company expanded from Minnesota into Wisconsin and Illinois with location-specific product variants, repair of address records the platform had accepted with the wrong state, transactional email consolidated onto one template system, and a refactor of address verification that had been re-checking the same addresses against a metered third-party API.

All of it was built by hand between 2015 and 2018. No scaffolding, no code assistant. The two-day production split was never in a requirements document; it came out of sitting with the kitchen and learning how the room actually worked. My part ended before the company did: I moved to Colorado and handed the platform off to an agency to carry forward, which is the right ending for a system a business has come to depend on weekly. Origin Meals was later sold to another meal-delivery provider and the site came down.