From Figma to a Live Product

This started as a personal challenge and turned into proof — that a designer with systems thinking and a CS background can own the full arc of a product, brief to build. The recipe book had to feel personal, not generic: warm meals and kitchen instinct, the kind of food content that lives in notebooks and group chats, not SEO recipe sites. So the direction was handmade, editorial, physical — pulling a card out of a box, not opening a tab.

The second goal was deliberate skill-building — learning React, Next.js, TypeScript, and Supabase through a real project with real errors, not tutorials.

Design began with three layout options in Figma. The chosen route — yellow and navy, Barrio for headings, Syne for body, organic cards, a polaroid stack — was specific enough to have personality but loose enough to evolve in code.

That transition exposed the central tension of design engineering: what takes five seconds to place in Figma can take 40 lines to approximate. A 2° rotation. A slightly oversized letter. A card that feels physically placed, not rendered. Every human touch needed a deliberate technical decision.

Three moments did most of the work. The homepage polaroid stack: on hover, photos shift greyscale → colour, a blue pantry card slides up from behind on a 300ms delay, and its z-index flips to overlap as it rises — three pieces of React state (hovered, pantryRaised, pantryOnTop), each on its own timer, so it reads as physical and sequential, not mechanical.

The hero type isn't typeset — each letter in 'RECIPE BOOK' is its own element with individual rotation and offset, the O's in BOOK a size larger, so it reads as hand-placed. And the recipe modal is built to feel like a card pulled from a box: #FFF8EC cream, a 0.5° rotation, SVG paper grain at 3.5%, ruled lines behind the text, em-dash bullets instead of dots. None of it is dramatic alone; together it shifts the modal from interface to object.

Two Supabase tables: recipes (title, slug, image URL, ingredients as JSONB, instructions, time, cost in ₹, calories, category) and pantry (items typed restock or leftover).

One early decision mattered most: shape classes and layout stay in the frontend, keyed by slug in a shapeMap. The database holds content, not design — so redesigning the layout never means touching the data. That's a design question that happens to need code to answer.

Three errors worth keeping. 'Cannot resolve @/lib/supabase' — the lib folder didn't exist; creating it taught me @ means project root. 'Invalid hook call' — useState sat outside the component; hooks only live inside function bodies. 'recipe is not defined' — a button used recipe.title outside the .map() where it existed; a lesson in scope.

A fully functional recipe book — live database, search and category filters, animated interactions, paper-textured modal — built by a designer in two weeks on Next.js, TypeScript, Tailwind, and Supabase.

What it proved: design thinking transfers straight into engineering decisions. Which fields belong in the database, where logic lives, what a modal should feel like — these are design questions that require code to answer. The fidelity gap between a Figma file and a working product closes with every build; this one closed it a lot.

Next: real food photography, five more recipes with full content, a Vercel deploy, and a second build applying everything learned here.