RobinFood

Dutch regenerative farms, contracted

12

Dutch production companies, onboarded

4

RobinFood was a marketplace for the produce Dutch farms could grow but not sell: good crops rejected on appearance, with no way to price them below "perfect." It let farms sell by grade, with sorting and cutting as services, to production companies that could not otherwise use them.

I was the founding product designer on a four-person team of founder, data scientist, engineer, and me. I owned research, product strategy, and the frontend, which I designed and built with AI. The company later became RegenOS, and I worked through that pivot too; the screens here are all RobinFood-era.

The subject is also personal: my grandfather, Alfred Brugger, led Switzerland's wheat and grain department and later became its minister of agriculture. Two generations on, this was my version of the same work — the trade of agricultural commodities, pointed at food waste.

The problem

I spent discovery in dozens of interviews with Dutch growers and production companies, and structured what they told me into a jobs-to-be-done corpus: 120 job statements across seven roles, built as data so AI could keep working with it through design. Underneath everything sat one finding:

The farmers put a number on it:

The buyer had the same problem, upside down:

The farmer cannot sell it; the manufacturer cannot use it. The sorting and cutting had to happen somewhere, and nobody owned it. That became what the marketplace sold:

The solution

Everything from here on is work I led: the strategy, the data model built with the data scientist, the flows, the screens, and the frontend code.

Six operations, one carrot

Before designing anything I mapped the whole chain and named six products we could build on it:

Then the positioning. I plotted the tools these companies already used on two axes and asked the founders to place us:

The model underneath

I built the data model with the data scientist, starting from a real grower's planning spreadsheet. It had a tell: columns for waste volume, almost always empty. Waste was not sellable, so nobody wrote it down.

The model resolved into seven domains:

Requests and listings are both batches, matched many-to-many: a 500 kg request is filled by several farms, which is why the buyer's dashboard leads with percentage fulfilled rather than an order status. None of this is hypothetical. It is visible in the pilot farm's real season plan:

Grade, specification, service

Grade is a first-class primitive and carries a price. The same crop lists as Grade A at €0.65 a kilo, Grade B at €0.45, Grade C at €0.35. Imperfect produce becomes a line item with a buyer.

Specifications sit beside grades: a Grade 3 carrot at 50–60mm is a different product from one at any size, and the request can say so.

Following one lot through the chain showed why services had to be their own thing:

So services became conditions on the trade: requirements a buyer sets that must be met before a supplier is allocated into the chain. The work itself is done by third-party providers who get paid for it, so it costs extra and shows up in the contract. The production company will buy Grade B once it has been through a cutter.

Spot or request

There were two credible ways for a buyer to get produce, and for a while we designed both:

1. 1

   Flow 1: browse the spot market

   Search a commodity, filter, add to cart, check out. A shop: it works the instant there is stock on the shelf, and not one minute earlier.

2. 2

   Flow 2: post a request

   State commodity, volume, target price, grade, services and date. Farms answer with offers; you compare and accept. Works with an empty warehouse.

We went request-led. A purchase order starts from a demand-side need; nobody browses for carrots. Matching was a human trader at first, on purpose: every manual match was training data for the automation that would replace them.

The supply chain as a graph

After the trade, production companies describe what happens to the crop. The industry stores that as a table; we drew it as a graph, because the graph is what the auditor requires:

Built in that shape, the compliance document becomes a byproduct of setup instead of a week of redrawing each year. Every branch is another sellable output (the team called it valorization), and AI drafts the first version from a plain-language description.

Two users, two complexity budgets

The same system serves a farmer checking prices between jobs and a production planner living in it all day, so the two sides got deliberately unequal interfaces.

The farmer product has five core modules: revenue, orders, crops, help and settings. Incoming requests are the heart of it.

The production product has twelve modules, because four jobs share one account: buying, running the lines, meeting the auditor, chasing the invoice. The split came from the jobs-to-be-done corpus. Density is a feature here and a failure two screens earlier.

The design-to-code pipeline

I designed and built the frontend with AI, and in February 2026 wrote it up as an architecture proposal: design velocity was capped by frontend engineering capacity, and hiring for it would have spent the runway.

1. 1

   Research

   Establish the technical patterns and constraints before design starts.

2. 2

   Figma: flows and IA only

   No pixel-perfect screens; production fidelity gets decided in the component library.

3. 3

   Component library in React + Tailwind

   The design system as real code, maintained by designers, consumed by engineers.

4. 4

   AI as pair programmer

   Claude Code wires components to state and API contracts while the designer stays in product thinking.

5. 5

   Sandbox

   Working software in front of stakeholders instead of static mockups.

6. 6

   GitHub as the boundary

   Pull requests, not handoffs. Engineers review and merge.

The core argument: consistency is enforced through code, not documentation. Change a component and every screen changes; break its API and the type errors say where.

The impact

RegenOS moved the product a layer down, from trading the harvest to an operating system for the farm, built on the second research finding: no insight. I stayed on to design it.

My brief was a translation job. The data scientist's dashboard fused satellite indexes, radar and weather; it was correct, and almost unreadable. I rewrote it as problem–solution fit, in the farmer's sentences:

One control matters most: the farmer sets the alarm threshold. A system that flags every deviation trains its users to ignore it. The dashboard shows what is happening and stops there; it supports the decision, the farmer keeps it.

Learnings

One idea never shipped: an emissions subsidy, minted by a platform treasury and applied at the moment of purchase.

It was cut, rightly: it needed a token economy before the marketplace had a single completed transaction. What I keep from it, and from the whole arc:

• Learning

  Value lives in the transaction, not the marketing

  Grade as a column, service as a priced condition, emissions as a price: three attempts at one idea. A sustainability product becomes real in its data model or stays a poster.

• Learning

  Manual first, then automate

  The human trader was not a compromise: every match they made was ground truth for the algorithm that would replace them. Launching with the algorithm would have been guessing.

• Learning

  Know why the prototype worked

  The no-code tool's one-table limit leaked into the first schema. Knowing which parts of a model come from the domain and which from the tool is most of the work of throwing a prototype away properly.