Hey and welcome back to a new week!

In this issue:

• Build a Live Prototype From Your Figma Design: When Lovable is enough, when Figma MCP matters, and how to scope a prototype that feels real.

• Debodyuti’s Portfolio: A real masterclass in calm but visually impressive storytelling.

Thank you for reading!

🤑 TRADE ON ANYTHING ON THE NEWS

Trade Real-World Events. Get $10 Free.

Start trading real-world events. With Kalshi, you can trade on things you already follow: inflation, elections, sports, and more. It’s simple: buy “Yes” or “No” shares on what you think will happen, and earn returns if you’re right.

To get you started, we’re giving you a free $10. Use it to explore the platform, test your instincts, and see how prediction markets work in real time.

Join thousands already trading the news and putting their knowledge to work.

Claim your $10 and start trading now.

Put $10 to Work

_{Trade responsibly.}

How to Turn a Figma Design Into a Live Prototype With AI Coding Tools 🧑‍💻

There are two very different reasons to use AI for prototyping.

The first one is quick concept validation. You do not have a finished design yet. You have an idea, a rough wireframe, a few gray boxes in Figma, or a flow you want to make tangible quickly. I have covered this kind of workflow in workshops before, and for that, Lovable can be great. You describe the idea, maybe paste a rough sketch, and it gives you something that feels like a working app surprisingly fast.

That is useful when the goal is exploration. You are not trying to perfectly recreate a designed interface. You are trying to answer: does this concept make sense once people can click, type, and move through it?

The second use case is different.

Sometimes you already have a design, and the details matter. Maybe you are prototyping a change to an existing product where users already know the interface. Maybe the concept depends on specific interactions, spacing, motion, or visual hierarchy. Maybe you want people to react to the product idea, not to the weirdness of the prototype.

That is the workflow I want to cover here, because it is a bit more advanced and I have not talked about it as much:

Figma MCP plus an AI coding tool like Cursor, Claude Code, Codex, or another coding agent.

This is also much closer to the kind of prototyping I now use at work. The goal is not to make a full production app. The goal is to build a believable live slice of the design: something that runs in a browser, accepts input, handles a few states, responds to screen size, and feels much closer to software.

For a portfolio, that can be a strong signal. Not because you used a trendy tool, but because you made the design real enough to test.

Why Not Just Prototype in Figma?

Figma prototypes are fine for simple click-throughs, but they become painful when you want realistic behavior. Wiring frames together takes time, inputs are awkward, state changes are limited, and anything that should feel like real software usually needs hacks. A code prototype can make a text input, filter, modal, validation message, responsive layout, or dynamic list feel real with much less effort, especially when AI is writing most of the implementation.

So if you are still spending hours wiring noodles between frames to fake an app, it is worth looking at this workflow.

Which Tool Should You Pick?

The difficult part is that all these tools sound like they do the same thing.

Lovable. Cursor. Claude Code. Codex. Figma MCP. Vercel. GitHub. Netlify.

If you are new to this, it can feel like a wall of names.

So I would simplify the decision.

Use Lovable when you want the fastest path from idea to working thing.

Lovable is strong when fidelity is not the main point:

• You want to prototype a concept before designing it properly.

• You have rough wireframes and need a fast working version.

• You want to test whether an idea makes sense as a flow.

• You want to build a small tool, calculator, visualizer, or playful interaction.

• You want to create a portfolio playground project without turning it into a full case study.

The big advantage is that Lovable handles a lot of annoying setup for you. You do not need to think much about local development, deployment, hosting, or wiring everything together before you can share it. You can get to a hosted, working-feeling prototype quickly.

That is amazing for small projects.

It is also why Lovable can be a strong fit for portfolio playgrounds. A lot of good portfolios now have some kind of playground section: small experiments, live tools, interaction studies, tiny products, or weird little builds that show curiosity. The point is not pixel perfection. The point is making something alive enough to explore.

The downside is accuracy.

If you need the prototype to closely match an existing Figma design, Lovable is usually not the tool I would reach for first.

But if the assignment is:

"Take this existing Figma design and make it feel as close as possible to the real product,"

then I would reach for Figma MCP and a coding agent.

The tradeoff is that this path usually has more setup. You may need a local project, a development server, GitHub, deployment through something like Vercel or Netlify, and a bit more patience. I am not going to cover all of that setup here but happy to do so in another issue if that is a blocker for people.

But the payoff is accuracy and control.

And when it comes to choosing between Cursor, Claude Code, Codex, or another agent, I would not overthink it too much. People will argue that one is better than the other, and sometimes they are right in very specific ways. But for this kind of prototype, they are similar enough that the best tool is usually the one you already have access to and feel comfortable using.

If you have access to one of them, start there.

If you do not, try whichever one you can test easily and see what feels most natural.

If the final prototype is good, nobody cares which tool made it.

When Figma MCP Matters

MCP stands for Model Context Protocol. You do not need to get too deep into the technical side to understand the benefit.

The useful version is this:

Instead of asking AI to guess from a screenshot, you give the coding agent structured access to the design.

Depending on the setup, the agent can inspect things like frames, layer structure, component names, spacing, colors, typography, and assets. That is a much better starting point than a flat screenshot.

If you want to set it up, start with Figma's own Guide to the Figma MCP server or the shorter Get started with the Figma MCP server page. Figma also has setup guides for Cursor, Claude Code, and Codex.

One important caveat: do not assume the free plan gives you the full useful version of this workflow. Figma's docs say the remote server is available across seats and plans, but some seats may have usage limits, and more advanced write/canvas workflows require the right seat and plan. So if the MCP feels weirdly limited, it might not be your fault. You may need a paid Figma setup to get something meaningful out of it.

This matters when accuracy matters.

For example:

• You are prototyping a change to an existing product interface.

• You want users to react to the idea, not to a rough approximation.

• The design relies on specific spacing, hierarchy, or visual polish.

• You already have a mature Figma file with components and tokens.

• You want to create a live portfolio prototype that clearly relates to the original design.

The closer your Figma file is to a real design system, the better this can work.

If your design already uses tokens for colors, spacing, typography, radius, and components, that helps a lot. It gives the agent a structure it can reuse instead of hardcoding random values everywhere. That makes the first prototype cleaner, but it also makes future iterations easier. If you later build a second prototype from the same system, you do not want to start from scratch every time.

This is one of those quiet advantages that matters more than it sounds: a tokenized design is easier for humans to implement, and it is also easier for AI to implement.

Start With One Live Slice

The biggest mistake is trying to build the whole product.

Do not do that.

Pick one focused flow that proves the thing you care about.

For example:

• A dashboard where a user filters a list and opens one detail view

• An onboarding flow where a user answers three questions and sees a personalized result

• A job tracker where a user adds an application and updates the stage

• A finance tool where a user categorizes a few transactions

• A settings page where a user changes permissions and sees a confirmation state

The prototype should be small enough that you can review it properly: one flow, two or three key screens, a few realistic states, and maybe one responsive breakpoint.

Scope is what keeps the project useful.

Step 1: Clean Up the Figma File

Before you ask an AI coding tool to build from your design, make the design easier to read. You do not need to make the file perfect, but you should create a clear source of truth.

That means:

• Put the target flow in one obvious section.

• Name the key frames clearly.

• Name important components and layers.

• Remove old explorations from the build area.

• Make sure the relevant assets are available.

• Use existing tokens and components where possible.

• Add short notes for behavior that is not obvious from the screen.

Treat the agent like a very fast junior developer. It can move quickly, but it still needs a good brief. If you give it a messy Figma canvas with six abandoned directions, do not be surprised when it builds the wrong one.

Step 2: Use an LLM to Scope the Build

Before prompting the coding agent, use ChatGPT, Claude, or another LLM to help you turn your idea into a clear build brief.

You can say:

I want to build a live prototype from a Figma design.

Help me scope this into a clear coding-agent brief.

The prototype should show:
- The main dashboard
- An add-item modal
- A working form with validation
- A list update after saving
- An empty state
- A mobile version

It should not include:
- Login
- A real backend
- Payments
- Admin features
- Anything outside this flow

Ask me clarifying questions if the scope is still too vague.

This helps because designers often describe intent, while coding agents need implementation clarity. The LLM can help translate:

"I want it to feel realistic"

into:

"Use local state, realistic sample data, working inputs, inline validation, an empty state, and responsive behavior. Do not add backend services."

Good prompting is not about sounding clever. It is about removing ambiguity.

Step 3: Let the Agent Inspect the Design First

Once your Figma MCP setup is connected, do not immediately say "build this."

Ask the agent to inspect the relevant frame first.

For example:

Inspect this Figma frame and summarize the layout, components, visual style, and likely interaction states.

Do not write code yet.

Tell me what you think the user flow is, what components you see, and what parts may need clarification before building.

This gives you a chance to catch misunderstandings early. If the agent thinks the side panel is a navigation menu but it is actually a filter drawer, correct it. If it assumes a backend is needed, tell it to mock the data locally. This is much easier than fixing the wrong build later.

Step 4: Generate a Narrow First Version

Now you can ask for the first build.

Keep the prompt strict:

Using the Figma frame and the build brief, create a live front-end prototype of this flow.

Build only the scoped flow.
Match the Figma design as closely as possible.
Use the design tokens and reusable components where available.
Use local state and realistic sample data.
Mock anything that would normally require a backend.
Do not add authentication, extra pages, or unrelated features.

After building, tell me what files you changed, what works, and what is still incomplete.

This is the middle ground. You are probably not building inside the real company app, because most junior designers will not have that access, and even inside companies the developer environment can be too heavy. But you are also not making a loose screenshot approximation. You are building a realistic mock version of the designed flow.

Step 5: Review It Like a Designer

When the prototype runs, use it like a real product. Click through the flow. Resize the browser. Type long text. Leave required fields empty. Try the empty state. Look at the mobile view. Check whether the hierarchy still matches the Figma design. Notice where the AI made generic choices.

Then make a short punch list:

• The card spacing is too loose compared with Figma.

• The modal works, but it hides context the user needs.

• The form needs inline validation.

• The empty state copy is too generic.

• The mobile layout should prioritize the task list before the stats.

• The tokens are inconsistent: the build uses three similar blues instead of one.

That last example is important. Do not only review the surface. Review the system. If the agent hardcoded colors, spacing, and font sizes everywhere, ask it to clean that up. A prototype does not need perfect production code, but a reusable token structure makes it much easier to iterate.

Step 6: Iterate in Focused Passes

Do not ask the agent to fix everything at once.

Work in passes.

For visual fidelity:

Compare the current build against the Figma frame. Focus only on spacing, typography, colors, radius, component styling, and visual hierarchy. Do not change functionality.

For interaction:

Keep the visual styling unchanged. Improve the form interaction with validation, a success state, and a clear cancel path. Use local state only.

For responsiveness:

Keep desktop unchanged. Improve the mobile layout so the primary task remains easy to complete on a narrow viewport.

For cleanup:

Review the implementation for hardcoded design values. Extract reusable tokens or constants for repeated colors, spacing, typography, and radius. Do not change the UI.

This is where the workflow becomes powerful. The first prompt gets you something. The focused passes make it good.

Step 7: Share It Properly

Once the prototype is good enough, you have a few options. You can deploy it with something like Vercel, Netlify, GitHub Pages, or another simple hosting setup, depending on the stack. If that is too much, record a short walkthrough video or GIF instead.

For a portfolio, I would include:

• The original Figma design

• The live prototype or a short interaction recording

• One paragraph explaining the scope

• Two or three things you learned after making it interactive

• One before-and-after improvement

Be honest about what it is.

For example:

"This is a focused front-end prototype of the application-tracking flow, not a full production app. I used Figma MCP and an AI coding agent to turn the designed flow into a live version, then refined the interaction, empty state, and mobile layout after testing it."

That is a strong portfolio moment. It shows the design, the build, and your judgment.

What This Proves

This workflow does not mean every designer needs to become an engineer. But it does help you understand how design becomes software. You start noticing things that static screens hide: missing states, awkward forms, weak responsive behavior, unclear copy, components that do not scale, and design tokens that are not as consistent as you thought.

That is valuable.

Especially for junior designers, because it gives you a more concrete story in interviews:

"I designed this flow in Figma, then used Figma MCP with an AI coding tool to build a live prototype. The first version exposed issues with validation, mobile hierarchy, and empty states, so I refined those before adding it to my portfolio."

That story is much stronger than "I made some screens." It is also stronger than "I used AI." The point is that the tool helped you make the design more real, and once the design is more real, you can make better decisions.

The Simple Version

If you want to try this, keep the first attempt small:

1. Pick one Figma flow with two or three screens.

2. Clean up the frames, layers, components, and tokens.

3. Use an LLM to turn the idea into a clear build brief.

4. Connect your coding tool to Figma MCP.

5. Ask the agent to inspect and summarize the design first.

6. Correct the summary.

7. Generate a narrow live prototype.

8. Review it like a designer.

9. Iterate in focused passes.

10. Deploy it or record a walkthrough.

11. Add the learning, not just the link, to your portfolio.

That is enough.

You do not need to build the whole product.

You just need one slice that feels real enough to learn from.

💌 STAY UPDATED ON AI IN JUST 5 MINUTES

Learn AI in 5 minutes a day

You don't have to scroll every AI thread, track every new tool, or watch every demo. 

The Rundown AI breaks it all down for you — the latest AI news, tools, and tutorials in one free 5-minute email every morning. 

Trusted by 2M+ professionals at Apple, Google, and NASA.

Sign up to start learning.

👀 Portfolio Showcase

Today: Debodyuti Biswas

Debo’s portfolio feels more mature than a lot of early-career portfolios.

That makes sense. He has already worked for around three years and is now doing his master’s in Information Experience Design at Pratt. So yes, he has more experience than many students or recent grads I usually feature here.

But that also makes the portfolio worth studying.

Because you can see what a few years of practice can do. The work feels considered. The structure is calm. The presentation is confident. And across the portfolio, there is a clear sense that Debo knows what to show, what to hold back, and how to create a strong impression without overexplaining every decision.

There are still a few things I would refine, but the foundation is strong.

That’s it for this week—thanks so much for the support! ♥️

Do you want your own portfolio reviewed in-depth with a 30-minute advice-packed video review? Or do you require mentoring to figure out a proper strategy for your job search?

I got you!

• Book an in-depth portfolio or resume review with me

• Book a mentoring session with me

• Book a quick 15 min chat to ask a question and see if we vibe

Keep kicking doors open and see you next week!
- Florian