Beukers Koken

The client runs a cooking account where every recipe he has ever made lives only in an Instagram caption: a paragraph under a photo, no real method, no way to scale a recipe up for six people, and nothing that reflects the account he has actually built an audience around. He wanted a real site: fuller recipes, findable ones, and a portfolio that mirrors the feed instead of competing with it.

We started in Framer, the same place most visual-first client sites start. Framer's whole model is drag-and-drop: it was never built to be owned from code, imported in one shot, and still stay editable by hand afterward. I wanted to build the site from Claude Code and still hand the client something he could open and edit himself. Framer could give me one of those, not both.

Drop Framer and rebuild the site as a code-owned Next.js app with a git-based CMS, so the whole thing builds straight from the repo while the creator still edits recipes inline without touching a line of code.

I started this one in Framer, the same way most of my client sites start when the brief is "make it look good and let me touch it myself afterward."

The brief itself was simple. Every recipe this client had ever cooked lived only as an Instagram caption: no real method, no way to scale it for a dinner party, and no site that reflected the account he'd spent years building. He wanted people to actually find a recipe when they needed it, not scroll back through a feed.

Framer got the design far enough to see it was right, warm and food-forward rather than another dark, techy portfolio. Then I hit the actual problem, which had nothing to do with the design.

So I dropped Framer and rebuilt the whole thing as a code-owned Next.js app with a git-based CMS. Recipes are files in the repo instead of rows in someone else's database, which means the site builds from code the way I want it to, and the client still edits inline through a visual editor without ever seeing a line of it.

Getting the toolchain to behave took a bit of stubbornness of its own. The CMS needed native builds that plain npm choked on, so I moved the project to pnpm and explicitly allowed the packages that needed compiling. Small, fixable, but it would have quietly broken a first deploy if I hadn't caught it early.

With the plumbing sorted, the fun part was the data model. Each recipe carries its ingredients as structured amounts and units rather than a paragraph, which is what makes the portions calculator possible: scale a recipe from four servings to eight and the ingredient list recalculates itself, fractions and all, while items that shouldn't move (a pinch of salt, a squeeze of lemon) stay put. The site also pulls the creator's own Instagram feed in live, through the official Graph API with a small server-side proxy so the access token never touches the browser.

The result is a site that looks like the warm, hand-cooked feed it mirrors, but runs on a system where the client adds a recipe without needing a developer, and I can still build on top of it without fighting a page builder to do it. It lives in its own repository, separate from anything else I maintain, which is exactly the point: it's his platform, not a rented one.