The Weekly

Problem

I’m a meal kit subscriber. There. I said it.

Why? Not the pre-portioning. Not the recipes. Definitely not the double-the-supermarket price. I buy them because every time my wife and I try to pick a week of meals, we either give up or fall back to the same boring old regulars.

Six months ago, working on Coles’ shoppable recipes team, it clicked: supermarkets already deliver groceries and publish recipe libraries. Nobody had glued them into a proper planning experience.

The idea sat in the back of my mind, destined to be another one of those ideas that sits there for a while and then evaporates, killed by the lack of time to experiment. Then I succumbed to the virality of Claude Code, needed a real project to try it on, and realised this one could ship frontend-only.

Decisions

Picking an idea with a pre-solved integration

The enabling insight: Coles already has a public URL for adding items to trolley, used for its shoppable recipe partnerships. Picking an idea with a pre-existing integration lets me create something usable end-to-end, without needing to build a backend. Perfect scope for playing with Claude Code for the first time.

Opinionated UX over feature breadth

Next, the scope. I believe most products don’t take strong enough opinions about what users should do to get a great experience, and as a result, end up dropping users into an open field of options, where they inevitably take a subpar path.

When deciding what I’d include in The Weekly, I cut, cut, and cut some more. My goal was to reach the level of simplicity of meal kit ordering, but via a supermarket. I limited meal choices to 3–6. Stripped ingredient review to the essential information, cutting product information clutter. And above all else, I ensured a completely linear user flow. No branching, just follow the flow to reach the goal.

There’s always great reasons to add one more feature. Someone will love it. That’s feature gravity. But every extra option, every extra feature erodes the simplicity of the experience, and a simple, low-thinking experience was the whole goal of this project.

Real recipe data

Manufacturing realistic data for The Weekly would’ve been painful: every recipe needed matched sellable products to be able to use the trolley integration. I decided The Weekly needed real recipes with matched products from Coles.

scroll →

Coles publishes recipes online but doesn’t expose an API. So I asked Claude Code to scrape 50 pages. Claude installed Playwright, and wrote a script to download a local copy of those pages. Afterwards, it wrote a Node.js script to transform the semi-structured page data into clean JSON to use as the data source for The Weekly’s UI. It took a few iterations to clean up the data (e.g. remove bad product matches), but with just an hour’s work, I had a clean dataset to use for the POC.

Outcome

A day later, I picked 5 meals, printed the recipes, and got the ingredients in my trolley, all in 2 minutes.

With a bit of creativity, I was able to get real data, and a real trolley integration. No mocking, just a working (if bodged together) experience.

When my wife tried it she got it straight away. Just watching her using it generated great insights: she found the ingredient review step unintuitive, and she never tried the (fully working!) print recipe or trolley integrations, because she assumed I couldn’t have made them work that quickly.

V1Day 1

First working version. No visual direction yet, default shadcn styling, no desktop layout.

V2Day 4

After a design audit pass and wiring into the workspace design system. Amber identity, desktop layouts, consistent token layer.

V1Day 1

First working version. No visual direction yet, default shadcn styling, no desktop layout.

V2Day 4

After a design audit pass and wiring into the workspace design system. Amber identity, desktop layouts, consistent token layer.

V1 Day 1V2 Day 4

After a design audit pass and wiring into the workspace design system. Amber identity, desktop layouts, consistent token layer.

Lessons

I didn’t write a line of code

When I picked up Claude Code, I expected a coding assistant. I expected to read every line of code, find some bugs, clean some things up. Then build, find some more bugs, and hand-fix. Reality: I didn’t touch a single line of code. I didn’t even need to read any code.

Design before build

But Claude also made baby’s first UI. Perfectly fine for POC, but far from polished. Inconsistency was the killer. Slight differences in spacing, too many button sizes, too many typography styles, and so on.

I went through many rounds of iteration over the next couple days, eventually landing at something that looked and felt a bit better. But after this experience, I resolved to use a proper token & component system for my next project, to bake in consistency in a structured manner from the very beginning.

Next

With a successful frontend-only POC using Claude Code, I next wanted to explore if I could build a working fullstack webapp.

Next project

Planner POC