Make is Figma’s most aggressive bet since multiplayer collaboration: it tries to collapse the distance between “we designed it” and “we can actually use it.”
Strategically, Make’s advantage is distribution and context: it starts where designers already work and can reuse existing components, libraries, and institutional knowledge, rather than generating in a vacuum.
Its biggest risk is trust: code quality, determinism, governance, and economic predictability.
The official product constraints are the tell - export is one-way to GitHub, publishing is public-web-first unless you pay for higher-tier controls, and “credits” are moving from soft limits to enforced limits in March 2026.
Community sentiment from mid‑2025 through early‑2026 follows a familiar arc: early excitement, then friction as teams hit reliability/hand-off limits and pricing becomes real.
The most realistic near-term outcome is that Make becomes a solid “interactive prototyping and alignment” layer, while production software workflows remain anchored in engineering toolchains - unless Figma materially improves the “eject to production” story and enterprise controls.
Execution is getting cheaper - we all know this.
When the cost of producing a plausible UI drops, the competitive advantage shifts from drawing to deciding: system constraints, interaction correctness, and organizational alignment. Make is Figma’s attempt to own that new center by making “the first runnable draft” live inside Figma rather than in an IDE or a separate AI builder.
That’s why this is a make-or-break moment.
If Make becomes the default way teams validate ideas in motion - and those prototypes are reliable enough to become the starting point for engineering - Figma expands into the software creation loop.
If Make is treated as a demo generator that produces generic, hard-to-maintain code and unpredictable costs, users will keep it at arm’s length and use faster code-native workflows elsewhere.
Right now, it looks like it will be the latter.
Make is best described as a prompt-to-interactive sandbox that is unusually good at one thing: turning design intent into something clickable fast, without leaving the collaboration environment that already holds the team’s source-of-truth designs.
Make’s value is not “AI can generate UI.” Many tools can. The differentiated features are those that connect generated prototypes to real team workflows:
Prompt + context creation: generate a functional prototype or lightweight web app from a prompt, optionally anchored by imported design context (frames, visual reference).
Iterative editing loop: refine outputs through conversational edits with live preview, treating changes as an interactive back-and-forth rather than one‑shot generation.
Embed where decisions happen: prototypes can be embedded into other Figma surfaces for review and alignment (so prototypes become living artifacts inside critique/review workflows).
Publish to the public web: publish to a
figma.sitedomain, update/unpublish, and configure basic metadata; higher tiers include internal-access controls.Custom domains: support for custom domains and DNS requirements, with limits depending on plan.
GitHub push (constrained): one-way push to GitHub with explicit limitations (repo constraints, branch limitations, no two‑way sync).
Model choice via “experimental models”: ability to switch models globally, signaling a multi-model strategy rather than a single fixed provider.
Context portability via MCP: broader Figma push to make design context accessible to AI tools and agents, including Make-related updates (important roadmap signal).
So what did Figma steadily make possible, and what does that imply? The official blog and help-center arc shows: an initial launch, rapid best-practices guidance, broader access/GA positioning, model diversification, and then an explicit move into economics through credits and enforcement.
Sources for those dated signals are Figma’s own blog and help docs, plus reputable coverage documenting MCP expansion and the strategic intent behind it.
Figma is building for a world of multiple AI agents and tool surfaces, where Figma’s competitive defense is being the canonical design context layer.
The push around Model Context Protocol and a dedicated Figma MCP server is a clear indicator that Make is not meant to be isolated—it’s meant to plug into a larger AI workflow graph.
Figma has disclosed enough to infer a “portfolio” strategy, but not enough to describe internal routing, fine‑tuning, or evaluation approaches (those should be treated as unspecified).
Disclosed at launch: Make was described as using Anthropic’s Claude 3.7 Sonnet at introduction.
Disclosed later (default model): Figma’s AI credits documentation describes Make’s default model as “optimized for Claude Sonnet 4.5.”
Disclosed as optional: Figma’s “experimental models” feature explicitly points to alternative models such as Gemini 3 Pro; Figma’s own blog post confirms availability.
Unspecified: internal orchestration (router models, safety filters, code execution sandbox details, eval benchmarks), and exact model versions beyond what’s named above. (No invention: not publicly documented in the cited sources.)
The official docs and hosting details point strongly to a cloud-first implementation.
Published Make outputs are hosted on Amazon Web Services and served through Cloudflare. That’s explicit.
None of the official documentation surfaced here describes on-device inference; treat on-device execution as unspecified/not supported unless Figma documents it.
The most important integrations are those that define “can this become real work?”
Publishing + domains: publish to
figma.site, configure metadata, add analytics IDs and custom code, and connect custom domains; internal access control limited to higher tiers.GitHub push (limitations are the story): one-way push, only to repos created by Make, always to
main, no two-way sync, no branch management, no GitHub Enterprise Server support. These constraints implicitly position Make as prototype-first rather than production-first.Backend path (official positioning): Make’s marketing and docs emphasize connecting to common backends (e.g., Supabase) for data/auth; this is how Make tries to cross from “prototype” to “app.”
MCP/connectors: Figma’s MCP server and Make-related MCP direction signal that the long-term bet is “context flows wherever you build,” so Make can be part of an agentic toolchain rather than a single tool.
Designer sentiment isn’t monolithic, but it’s consistent in shape: praise for speed and stakeholder leverage; criticism about sameness, reliability, and “unrealistic handoffs.”
The credible adoption pocket is teams who need interactive artifacts early. Figma’s own case studies frame Make as a way to prototype complex interactions under time pressure and to communicate product behavior more effectively than static mockups.
In the community, the most common “I tried it” posts are experiments: small UI concepts, micro-interactions, prompt-driven layouts, and “look what it generated” prototypes.
On Dribbble, posts tend to skew positive and exploratory, emphasizing novelty and speed.
Fast path to clickable prototypes: teams can test flows and share behavior early, reducing ambiguity in critique and stakeholder review.
Better conversations: embedding prototypes into the same surfaces where planning and reviews happen encourages feedback on behavior rather than speculation.
“Good enough” scaffolding for experts: senior designers often value Make as a draft generator they can reshape, not as an oracle. (This is consistent with how Make best-practice guidance is written: instruct the model, constrain it, iterate.)
Sameness / generic aesthetic: public discussions argue Make outputs converge on common UI patterns and “default modern SaaS” visuals, reducing differentiation.
Code quality and handoff reality: developers and designers often warn that generated code is brittle and shouldn’t be treated as production-ready; community threads specifically call out “spaghetti” code and limited portability.
Economics skepticism: “credits” pricing is widely disliked when it feels opaque or hard to forecast, and Figma’s move toward enforced limits makes this criticism more relevant.
The right comparison is not “who has AI,” but “who changes the cost structure of getting to a believable artifact” and “who integrates into real pipelines.”
What it changes
• Lowers the cost of visual exploration
• Reduces blank-canvas friction
• Speeds up mock generation inside Figma
What it doesn’t change
• The design → handoff → rebuild model
• Engineering translation cost
• System-level architecture
Pipeline impact
• Stays inside the design phase
• Produces believable visuals, not believable systems
It accelerates craft. It doesn’t compress delivery.
What it changes
• Dramatically lowers cost of getting to a live MVP
• Skips mock layer entirely
• Produces functional, deployable output
What it doesn’t change
• Deep enterprise customization
• Long-term architectural discipline
Pipeline impact
• Collapses design + prototype + deploy into one motion
• Eliminates handoff
This changes the cost of functional plausibility.
What it changes
• Lowers cost of generating production-ready UI
• Outputs real React + Tailwind code
• Often aligns with shadcn patterns
What it doesn’t change
• Backend systems
• Complex multi-service architecture
Pipeline impact
• Compresses design → frontend boundary
• Integrates directly into real repos
This is a bridge tool. Not mock-first. Not full-stack. But real.
What it changes
• Lowers cost of modifying real production code
• Understands repository context
• Handles multi-file edits
What it doesn’t change
• Need for strong product judgment
• Poor architecture if it already exists
Pipeline impact
• Lives inside the engineering loop
• No handoff required
This reduces the cost of evolving systems, not generating screens.
What it changes
• Increases engineering throughput everywhere
• Reduces cost of writing repetitive logic
• Speeds up implementation across teams
What it doesn’t change
• Product thinking
• Cross-file architectural reasoning (deeply)
Pipeline impact
• Integrated into IDE
• Accelerates code, not design
When engineers move faster, mock-first workflows become the bottleneck.
Claude.com/product/claude-code
What it changes
• Lowers cost of restructuring complex systems
• Handles multi-file architectural edits
• Reasons across larger codebases
What it doesn’t change
• Need for disciplined prompting
• Bad system foundations
Pipeline impact
• Deep integration into real repos
• Operates at architecture level
This is closer to “AI mid-level engineer” than UI generator.
What it changes
• Very low cost to build and deploy full-stack apps
• Accessible for solo builders
• AI-assisted development in-browser
What it doesn’t change
• Enterprise-grade scalability
• Complex org-level workflows
Pipeline impact
• All-in-one build + deploy environment
• Skips traditional ceremony
It optimizes speed over control.
There are two fundamentally different games:
Game 1
• Accelerate mock generation
Game 2
• Accelerate system creation and evolution
Figma Make strengthens Game 1.
Lovable, v0, Cursor, Claude Code, Copilot, and Replit strengthen Game 2 in different ways.
Make’s strongest advantage is context + collaboration - a rarer combination than it sounds. Many tools can generate UI. Fewer can generate it while anchored to the organization’s actual design artifacts and then circulate it through the same review surfaces teams already use.
Make also has a credible “web outcome” loop. Publishing to figma.site (plus domains) means the output isn’t just a prototype in a file; it can be deployed as a link that behaves like software, which increases its political power inside organizations.
Finally, the multi-model / MCP direction is a genuine strategic hedge. Figma is implicitly conceding that model quality will be a moving target, so the platform advantage becomes: “our context travels into whatever model/workflow wins.”
Make’s main weakness is that it encourages a tempting story - “just export it” - while the official constraints show it’s not there. GitHub export is one-way and constrained; it’s not a real development workflow. That’s why developer sentiment in public threads often reads as “use it for demos, not shipping.”
The second weakness is economics and governance. Figma is moving toward enforcing AI credit use; teams will need predictable budgets and controls. Figma has documentation, but predictability and transparency are what will determine enterprise adoption once the novelty is gone.
The third is aesthetic and interaction determinism. If Make outputs remain “generic modern UI” without reliable design-system adherence, it risks being seen as interchangeable with cheaper/faster alternatives for early drafts.
The most realistic adoption scenario is that Make becomes the default prototyping layer inside product teams, replacing large swathes of static click-through prototypes and strengthening “prototype as a decision artifact.” Figma’s own case studies already point in this direction.
The most realistic decline scenario is that Make becomes a niche tool because it can’t become a stable bridge to production and because enforced credits make heavy use feel expensive relative to code-native workflows. Public skepticism around “credits” and export realism is already visible.
With so many players already so much closer to production systems, it’s hard to see a world where Make catches up - but that remains to be seen.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.