From Figma to Live URL: A Designer's First Afternoon of Real Code

Build something handy, not a fake app

Most coding tutorials have you build a to-do list, which is why most people abandon coding tutorials. You don't need a to-do list. Nobody needs a to-do list. You need something you'll actually open next week, because a tool you use is a tool you keep improving, and improving it is where the real learning hides.

So we're building a day-rate calculator for freelance designers. You feed it your target annual income, how many days a week you want to work, weeks of holiday, and monthly business costs. It does the math live and tells you what to charge per day. Sliders move, numbers update, and the answer is occasionally uncomfortable, which is how you know it's working.

This is also a deliberately Figma-proof project. A static mockup of a calculator is a screenshot of one answer. The entire point of the thing is the live math, the feel of dragging a slider and watching your rate jump when you give yourself four more weeks off. You cannot fake that with connected frames. That's the lesson hiding inside the tutorial: some ideas can only be evaluated as real software, and those are usually the interesting ones.

Here is the finished thing, live on this page. Drag the sliders, watch the day rate move, then come back and build your own with the steps below.

Swap in your own idea if you have one. A tip splitter, a contrast checker, a project timeline estimator. The workflow below doesn't care what you build, only that it's small and that you want it to exist.

The boring 15 minutes you only do once

The terminal is the app on your computer that takes typed commands instead of clicks. On a Mac it's called Terminal, and you can find it with Spotlight (press Cmd+Space, type "terminal", hit enter). On Windows, use PowerShell. It's a text box with a blinking cursor. That's the whole thing. Every scary screenshot you've seen of green text on black is someone's customized version of this text box.

First, install Node.js, which is what lets your computer run JavaScript outside a browser. Go to nodejs.org (https://nodejs.org), download the LTS version, and run the installer like any other app. Then confirm it worked by pasting this into your terminal and pressing enter:

node -v

If you see a version number like v22.x.x, you're set. That's your first terminal command, and notice that nothing exploded.

Next, install Claude Code, the AI agent that lives in your terminal and writes code in your project. One command:

npm install -g @anthropic-ai/claude-code

Quick translation: npm is the package installer that came with Node, install is the verb, -g means "globally, so it works everywhere on my machine," and the last bit is the package name. You'll need a Claude account when it first runs, and it'll walk you through logging in.

Finally, two free accounts if you don't have them: GitHub (https://github.com) (where code lives) and Vercel (https://vercel.com) (where deployed sites live). Sign up for Vercel using your GitHub account, which saves a step later. Done. You never have to do this section again.

Design it in Figma first (yes, still)

Skipping Figma and prompting straight into code sounds faster, and for throwaway experiments it is. But for this workflow the Figma step is doing something important: it forces you to make every design decision before you start building, which is exactly what makes your prompts good.

Open Figma and design one frame. A card on a soft background. Title at the top, four inputs (target income, days per week, weeks off, monthly costs), and a big result number at the bottom showing the day rate. Make the real decisions: your background color, your card color, your accent, your type sizes, your spacing values, your corner radius. Write them down, because in a minute you're going to say them out loud to a machine.

Here's the reframe that made this click for me: a prompt to a coding agent is a handoff document. You've written handoff docs before. You know the difference between "make it clean" and "16px padding, 12px radius, #0F172A text on #F8FAFC." The designer who is precise in handoffs is precise in prompts, which means you already have the core skill of this whole workflow and nobody told you.

Scaffold the project: four commands

Time to create the actual React project. Vite is the standard tool for spinning one up. Paste these one at a time:

npm create vite@latest rate-calculator -- --template react
cd rate-calculator
npm install
npm run dev

What just happened, line by line: the first command created a folder called rate-calculator containing a minimal working React app. The second moved your terminal into that folder (cd means "change directory," and it's the terminal equivalent of double-clicking into a folder). The third downloaded the project's dependencies. The fourth started a local dev server.

Your terminal will now show a link, usually http://localhost:5173. Open it in your browser. That's a React app, running on your machine, and here's the part that matters for the rest of your afternoon: leave it running. Every time the code changes, this page updates instantly. This is your live canvas.

Your first prompt is a handoff doc

Open a second terminal window (Cmd+N in Terminal), cd rate-calculator again to get into the project folder, and start the agent:

claude

Now paste in your design, described the way you'd describe it to a very fast, very literal engineer. Here's mine as a starting point. Change the values to match your Figma frame:

Replace the default app with a freelance day-rate calculator, one screen, no routing.

Layout: centered card, max-width 420px, on a full-height #F8FAFC background.
Card: white, 24px padding, 16px radius, subtle shadow.
Type: system font stack. Title "What should I charge?" at 24px semibold #0F172A.
Labels 13px medium #64748B.

Four inputs, stacked with 20px gaps:
1. Target yearly income: slider, 30k to 300k, step 5k, default 90k
2. Billable days per week: slider, 1 to 5, step 0.5, default 4
3. Weeks off per year: slider, 0 to 12, step 1, default 6
4. Monthly business costs: slider, 0 to 5000, step 100, default 500

Each slider shows its current value on the right of its label, 14px semibold #0F172A.
Slider accent color #6366F1.

Result block at the bottom, separated by a 1px #E2E8F0 divider:
label "Your minimum day rate", then the computed rate at 40px bold #6366F1.
Formula: (income + costs * 12) / (days per week * (52 - weeks off)).
Round up to the nearest 10. Update live as sliders move.

Put all styles in App.css, keep everything in App.jsx.

Press enter and watch. Claude Code reads your project, edits the files, and tells you what it changed. Flip to your browser tab. Your design is standing there, alive, doing math. The first time this happens it feels like a magic trick, and then about four minutes later it feels normal, which is its own kind of remarkable.

Notice what that prompt actually was: tokens, layout, spacing, states, behavior. You weren't "coding." You were doing design QA in advance.

Iterate at Figma speed, except it's real

Now the workflow becomes a loop, and the loop is fast. Look at the browser, notice what's off, tell the agent, watch it change. Real revision prompts from my session:

The result number jumps around as digits change. Give it a fixed-width font feature so it doesn't shift, and animate value changes over 150ms.

Add a small line under the day rate showing the hourly equivalent at 8 hours per day, 13px, #64748B.

On screens under 480px wide, reduce card padding to 16px and the result to 32px.

Each of those took under a minute to land. This is the pace argument for learning this workflow: you're not iterating faster than Figma, you're iterating at roughly Figma speed on the real thing, with real input handling, real text overflow, real everything. When something feels wrong, you're feeling actual software, and your critique gets sharper because of it. Try dragging the days-per-week slider to 1 and watch what your layout does with a five-digit day rate. Your mockup never had to survive that number.

A tip for when the agent does something you didn't want: don't fix it by hand, and don't accept it. Say what's wrong the way you'd mark up a design review. "The divider is too heavy, use #F1F5F9" teaches you nothing new; it's the same muscle you use every day, pointed at code.

Ship it: GitHub, then Vercel

Your prototype works, but it lives on your machine. Two more moves.

First, GitHub. Here's a nice secret about having an agent in your terminal: git, the version-control tool with the famously hostile learning curve, is something you can simply delegate. In your Claude Code session, type:

Create a git repository for this project, commit everything with a sensible message, create a public GitHub repo called rate-calculator, and push to it.

It may ask you to authenticate with GitHub the first time (it uses a tool called gh and will help you set it up). When it's done, your code has a home on the internet with a full history. Later, you can learn what commit and push actually mean, and I'd encourage it. Today, shipping matters more than vocabulary.

Second, Vercel. In your regular terminal window (not the Claude one), run:

npm i -g vercel
vercel

The first command installs Vercel's CLI. The second deploys. It'll ask you to log in, then ask a few questions about the project. Accept the defaults by pressing enter. Twenty seconds later it prints a URL ending in .vercel.app. Open it on your phone. That's your design, on the actual internet, built by you, today. When you're happy, vercel --prod gives you the polished production URL to share.

Total damage: four scaffold commands, two deploy commands, one delegated git request, and a handful of prompts that were really just handoff notes.

What changes when your work has a URL

The practical wins are obvious. Stakeholders test the real thing instead of a click-path. Usability tests stop needing a disclaimer about which buttons work. Your portfolio grows pieces people can use rather than watch.

But the deeper shift is in how you design. Once shipping a real prototype costs an afternoon, "would this idea actually feel good?" becomes a question you answer instead of debate. You start designing with an exit to reality in mind: cleaner tokens because you'll be prompting with them, sharper specs because a machine will take you literally, more curiosity about states and edge cases because you'll be the one watching them break at localhost:5173.

The honest counterargument is that prototype code is not production code, and an engineer will likely rebuild what you made. True, and it misses the point. Your prototype's job was never to be merged. Its job was to make the idea real enough to judge, fast enough to matter. The rebuilt version will be better because the conversation about it happened around working software instead of around a static mockup.

Designers have spent years asking for a seat at the table where build decisions get made. It turns out one reliable way to get there is to quietly become someone who builds. Pick the small handy thing you've been sketching in your head, give it your afternoon, and send me the URL when it's live.