How to design a product: from Figma to a working link without a developer

The designer made a layout, defended the stakeholders, handed over to the developer - and left to wait. Wait a week. Two. Then the edits, then "back not ready," then the release train left. After a month, the landing comes out - with other indentations, a different font and for some reason without half the animations.

Familiar? And this is where the interesting thing begins: a significant part of what the designer used to “give to the development”, today you can seal yourself. Not hand code, not layout from scratch, but to assemble a working product through a bundle of Figma, AI generation, no-code and a pair of buttons in cloud hosting. And get a real link where you can open the product from your phone in the subway.

It’s not about “designer replacing developer.” This is about the fact that there is no longer a separate person between the layout and the user, unless the task requires it. Landing, prototype for the hypothesis test, portfolio, internal tool, MVP for the investor - all this designer can bring to the product link himself.

## Why was it even possible

In the past, “getting it yourself” meant being able to build, configure the server, deal with DNS and environment variables. The stack looks different now.

• The layout in Figma can be turned into code through AI tools or copied as a finished component.
• Hosting is not a server, but a git push (or drag-and-drop folder altogether).
• The domain is connected in 5 minutes through the interface, not by editing configs.
• Databases, authorization, forms are taken as a service, without a backend.

That is, almost all the technical barriers that historically made deploy engineering work fell off. The only thing left is the ability to put it all together in a working chain. That's what we'll do.

### What is realistic to do yourself

Not everything. Realistic Designer Responsibility Zone:

• Landings and promotional pages - no questions asked.
• Prototypes for user tests with real data.
• Portfolio and personal sites.
• Simple SaaS-MVP: login form, dashboard, CRUD-interface.
• Internal team tools (mini-CRM, trackers, checklists).
• Documentation, design systems like websites.

What should be left to developers: complex business logic, integration with payment systems under load, everything where the price of error is money or personal data of users.

### Anti-pattern: "I'm going to lose money over the weekend"

The most common trap is to overestimate the complexity of the product. A designer sees a 12-screen interface and thinks, “I’ll put it together in an evening.” And then it turns out that between screens 4 — the calculation, which should coincide with the billing, and the roles of users with different rights.

Before you start, tell yourself:

• Is it an interface or a product with a state?
• Who is responsible if the data is lost?
• What happens if there are 1,000 users tomorrow?

If there is no clear answer to any question, it is not a task of “deploying yourself”. This is the task of "I make a prototype, then I need a developer.".

## Step 0: What should be in Figma before you click Export

The main reason why the automatic transfer of the layout to the code is ugly is that the layout was not ready for this. AI tools and plugins do not do magic. They work with what's in the file.

### File readiness checklist

• All screens on Auto Layout, without "naked" frames.
• Colors and fonts are rendered in styles or variables, not hammered into hands.
• Components are components, not grouped layers.
• The layers are humanly named card-product, not Rectangle 482.
• States (hover, active, disabled, empty) are collected in variants, not on different artboards.
• The grid and breakpoints are marked at 1440, 768, 375.

### Questions for self-testing before export

• If you remove one block, will the neighbors go correctly?
• Replace the text with a long one - the card is not broken?
• Opened the layout on the phone - read or turned into porridge?

A file that passes these three questions is transferred to the code with almost no pain. A file that does not pass – after export, it will require so many edits that it is easier to hire a layout designer.

### Summary of the section

Deployment doesn’t begin at the moment of the fluff, but at the moment when you assemble Figma as a system, not as a picture. Then there are the tools that will turn this system into a live link.

## Step 1: Choose the stack for the task, not for the hype

The most expensive mistake at the start is to choose a tool because everyone writes about it. After a week, it turns out that for landing you are dragging Next.js with a database, and for a SaaS-prototype, you took a designer, which does not climb authorization by magic link.

Before choosing, answer four questions:

• Is it a static (content does not change from user to user) or a state app?
• Do I need a database and login?
• Is this going to go to the developer, or is this the end point?
• What's your real code skill -- zero, reading and editing, writing simple?

Next is a rough map, no religion.

Задача	Что брать	Когда не брать
Лендинг, портфолио, документация	Framer, Webflow, или статика на Vercel/Netlify	Если завтра нужна сложная админка
Прототип с фейковыми данными	Figma Make, v0, Lovable	Если результат пойдёт в прод как есть
MVP с логином и базой	Lovable / Bolt + Supabase	Если в команде уже есть фронт-стек
Внутренний инструмент	Retool, Glide, Softr	Если данные нельзя выносить в SaaS

The main filter is where it goes next. The prototype on Framer can not be “advanced” into a combat product, it will have to be rewritten. It's okay if you know it in advance.

## Step 2: From layout to code without disaster

AI generation from Figma looks like magic only in the demo. The real file starts with what Step 0 is written for.

### A workflow that doesn’t fall apart

1. You take one screen, not the whole project. The most revealing, with components and states.
2. Run through the generator (Figma Make, Anima, plugin, MCP connector - what you chose).
3. You open the result and you compare not the pixels, but the structure: where Auto Layout turned into flex, where the component remained a component, where everything melted into divas.
4. Fix the source in Figma if the structure goes. If you don’t edit the code, you edit the layout and regenerate it.
5. Only when one screen behaves predictably do you scale to the others.

If you edit the code with your hands from the first screen, you have just hired yourself as a layout designer for a project without paying.

### Which usually breaks

• Long texts come out behind the cards, because in the layout the height was fixed.
• The icons are turned into png instead of svg because they are like pictures.
• The dark theme didn't work because the colors weren't variable.
• Everything fits on the mobile, because the breakpoint was “drawn”, not set.

All four problems are treated not in code, but in Figma. This is the main shift in the head: the layout is now a source, not a picture for matching.

## Step 3: Deploy and domain

Technically, it's the easiest step, and that's why they get stuck on it, waiting for a catch.

• Open an account on Vercel or Netlify, connect the repository (or drag and drop a folder).
• Push deploy. You get a temporary domain type project-x.vercel.app.
• You buy a domain from any registrar, add it in the hosting settings and copy DNS records to the registrar.
• You wait 10, 60 minutes. Done.

### “Before you give a link to someone”

• Opened your link in incognito mode – everything works without your login?
• Opened on a 4G phone, not an office WiFi?
• Checked favicon, page title and og-picture for sharing in messengers?
• Forms actually send data to where they promise, not to console.log?
• is a 404 a normal page, not a white screen?

## Typical revision errors

On the internal review of the projects sealed by the designer, the same list pops up:

• The product looks like a layout, but behaves like a prototype. The buttons are beautiful, but half doesn't lead anywhere. It is better to drink the non-workers than to leave them.
• **There are no download states and no errors. ** All is well as long as the internet is good.
• ** API secrets and keys are in the front code.** Anyone can see them through DevTools.
• There's no analytics at all. You don't know if what you rolled out works.
• There's no way to roll back. **Breaked, repaired on live users.

### Questions for self-examination before showing out

• What will the user see if the server responds with an error?
• Where are the forms stored and who has access to them?
• If you get sick tomorrow, can anyone support it?
• What exactly are you going to measure to see if it worked or not?

If there are no answers to these four questions, it is not a lost product. This is a publicly available layout and should be treated the same way.

### Short summary

Deploying a designer is not “push a button”, but to assemble a chain: a clean layout → an understandable stack for the task → predictable generation → an honest test on the market. A broken link anywhere turns all the work into a demo that can't be shown.

## When the team connects: the designer does not deploy in a vacuum

To roll out a landing page or an internal tool alone is a normal story. But as soon as the product becomes part of the basic flow of the company, there are developers, products, security professionals, lawyers. And then the designer-deployer is either built into the process, or his deploit quietly moves to the “normal” stack, and the work remains in the form of a reference.

### How to negotiate with developers in advance

• Show me the stack before you start coding. Not after. On a stack review, the team will either approve or offer its own - and that's cheaper than rewrite.
• Ask where the store is stored and who has access to the store. If the answer to “Seryozhya on the computer” is not a command, it is a bottleneck.
• Clarify what is considered a “product”: the main domain, subdomain, separate service. Landing on a subdomain usually does not scare anyone, but deployment on the root domain requires approvals.
• Find out who will fix it if it falls over the weekend. If no one else, you can’t leave on Friday.

### Anti-pattern: "I'll just show you and then we'll rewrite"

It sounds safe, but in fact, the prototype turns into a product by itself. After a week, traffic comes to the link, marketing tied advertising to it, support responds in form from there. It’s too late to rewrite the product. If you do not want your deploitation to accidentally become the main one, state it clearly: a mark on the page, a separate subdomain, a date of disconnection.

## AI tools: where they really help, and where they create debt

AI now knows how to pull a decent React component out of the layout, rewrite it under the right framework, throw states. It speeds up the routine a lot. The problem is that AI willingly generates code that looks right and works on a single screen but falls apart on scale.

### Where AI saves time without debt

• Translation of a static layout into an adaptive layout of one screen.
• Generation of typical components: forms, tables, cards.
• Selection of animations and microinteractions according to the description.
• Explaining someone else’s code when you need to understand what a piece of repository does.

### Where AI Creates Hidden Debt

• Project architecture: AI willingly duplicates logic in ten places because it doesn’t see the entire repository.
• Work with state and data: The generated code often stores everything in local states, and as the flow grows, this turns into mush.
• Security: AI will quietly put your key in the public code, if you entered it yourself in the Prompt.
• Availability: the generated layout is rarely checked by contrast, focus, ARIA - this must be repaired with your hands.

### Rule for MCP connectors and Figma plugins

The more closely AI is integrated with the layout, the more important the purity of the layout. If there is chaos of absolute positions and grouped layers with the names Group 47, the output will be chaos in the code. MCP is not magic, it amplifies what Figma already has.

## How to Check Quality Before Defending a Decision

Before you carry a link to the review team, run it yourself through the short list. It's not about perfectionism, it's about not getting a kick at a meeting about predictable things.

• Lighthouse in Chrome: Performance, Accessibility, Best Practices, SEO Numbers don't have to be green everywhere, but you have to understand why they're not green.
• Flowed off the keyboard, no mouse. If the focus is lost or the modal is not closed by Esc, it is a bug.
• Check with the JS off at least the first screen. There should not be a completely white page.
• Opened in Safari, not just Chrome. Half of the layout bugs live there.
• Measured the weight of the page. If the first screen weighs like a movie, you need to fix pictures and fonts.
• Checked that analytics really sends events, not silent.

## How to explain the decision to the team

On the defense of a deploy, the designer is usually asked the same thing: “why you, not the developers”, “why this stack”, “how we will support this”. Ready answers save half an hour of argument.

### The Explanation Structure That Works

1. Task and deadline. "We need a landing page for launch in two weeks, developers are busy with the main product.".
2. **Short: Framer, Webflow, code stack. Why did you choose this one.
3. Limits of decision. What does this deploit and what does not. To what extent does it live in its current form.
4. Transfer Plan. Who takes this to the main repository when the product takes off.
5. Risks and how they are closed. Secrets, backups, analytics, rollback.

### Questions to be prepared for

• What happens if you go on vacation and your website goes down?
• Where are the user data and under what agreement?
• How much does it cost per month and who pays for hosting and domain?
• If tomorrow the load grows ten times - what will break first?

If you have a short answer to these questions, deploy is perceived as an engineering solution, not as an amateur activity. If not, the team is right about it.

### Short summary

An advanced scenario is not “more technically difficult,” but “more honest about responsibility.” The designer who deploits takes on a piece of engineering work and must be able to protect it: with a stack, a checklist, a transfer plan and a clear answer to “what if it breaks.”.

## Final checklist: from Figma to live link

This is not a “perfect world”, but the minimum below which the deploit turns into a problem for the team. If on any point, the answer to "I don't know" is the place where you're going to rob yourself in a week.

### To deploy

• In Figma, the layers are human-named, autolayout on key sections, components are removed rather than copied five times.
• There is a separate dev branch or preview environment, the master does not ride directly from the laptop.
• All keys, tokens and passwords are in the variables of the hosting environment, not in the code and not in the repository.
• Pictures are compressed, fonts are loaded with font-display: swap or analog, the first screen does not pull megabytes.
• Meta tags, favicon, OG-picture checked through the preview of social networks, and not “later finish”.
• There is a 404 page and understandable behavior in empty states.

### At the moment of deploitation

• Domain is connected, HTTPS works, redirect from www to non-www (or vice versa) is configured once and for all.
• The sales and preview environments are visually different – at least with a banner, so that no one rules “the sale as a sandbox”.
• The rollback to the previous version is done with a single button and you checked it out, not just read it in the docks.

### After the deployment

• Analytics sends real events, not zeros. Checked incognito mode.
• Forms reach the recipient: letter, Telegram bot, CRM – whatever it is.
• There's a backup of content and a database, and you know where it lies.
• The calendar is a reminder of the extension of the domain and certificate.

## Anti-patterns that break even a good layout

### “I’m going to miss it, and then availability.”

"Then" doesn't come. If you do not initially lay normal contrasts, focus styles and semantics, you will have to redo the entire template. Availability is cheaper at the start than on top of a finished site.

### Hosting on a personal account

The company's website hangs on your personal GitHub and your personal Vercel card. When you go on vacation, no one can fix it. When you leave the team, the quest begins with the restoration of access. Any sale must live on an organizational account with two owners.

### One man knows all the magic

If you understand how to reassemble a project, where the secrets lie and where to look when the site is down, this is not independence, this is a bottleneck. At least one person on the team should be able to repeat the deploy according to your instructions on one page.

### Endless "temporary" landing

Made in a week landing lives two years, overgrown with crutches, and it already sits a form of payment. Agree on the shore: up to what metric or date this decision is considered temporary, and who is responsible for moving.

### Deploy without analytics

The site works, but you don't know how many people get to it, where and where they fall off. After a month, you don’t have the data to protect either the redesign or the existence of the page.

## Questions for a self-review

Before you close the task, run through the list. If the answer to any question is “you need to think” – the task is not closed.

• What will a person see when they open a website on a five-year-old phone?
• If you are removed from the project for a month, who and according to what instructions will roll out the edit in the hat?
• What three metrics will you be looking at in a week to see if it works at all?
• What will break first: layout, forms, analytics, domain, payment? Does each item have a responsibility?
• If a lawyer comes tomorrow and asks about cookies, consents and data storage, do you know what to show?

## Short practical outcome

Deploying as a designer is not “without developers,” but “taking on engineering responsibility for a particular piece of product.” Everything else is a consequence. The tool is selected for the task and lifespan, the checklist covers predictable risks, anti-patterns are caught before they become legas, and the team receives not a “site from the designer”, but an understandable solution with boundaries, owner and transfer plan. This is the difference between a one-off feat and normal work practice.